La gobernanza de prompts consiste en tratar los prompts como artefactos de producción: versionados, probados, auditados y atribuibles. En entornos regulados no es opcional.
Por qué los prompts son responsabilidades
Cada prompt que llega a un modelo en un sistema financiero o legal es una entrada de decisión. Los reguladores esperan explicabilidad y reproducibilidad. Un prompt modificado sin registro que produce una respuesta diferente hoy es una falla de auditoría.
Agregar logs no es suficiente. Los logs registran lo que ocurrió. La gobernanza controla lo que puede ocurrir.
Cuatro capas de gobernanza
Registro. Todo prompt en producción debe vivir en un registro versionado, con identificador estable, versión, estado, responsable, hash de contenido y fechas de aprobación o deprecación. Ningún prompt debe ejecutarse en producción sin estado aprobado.
Puertas de cambio. Promover un prompt de borrador a aprobado requiere revisión de diff, evaluaciones con umbrales definidos y registro de quién aprobó, cuándo y con qué resultado.
Pipelines de evaluación. Cada versión de prompt necesita un conjunto de pruebas con entradas y salidas esperadas. Corrección, tasa de rechazo, consistencia y latencia deben medirse por prompt, no solo de forma global.
Atribución en runtime. Cada llamada al modelo debe incluir prompt_id, prompt_version, caller_id y datos suficientes para reproducir la decisión. Esto crea una cadena causal completa entre decisión, versión del prompt y estado de evaluación.
Qué evita
- drift silencioso de prompts;
- cambios no aprobados en producción;
- no saber qué versión produjo una respuesta;
- decisiones imposibles de reproducir después.
El punto de partida mínimo es directo: una tabla Postgres como registro, una etapa de CI que ejecute evaluaciones en PRs y un middleware que rechace llamadas a prompts no aprobados. Las implementaciones más maduras agregan una API de gobernanza, dashboards de evaluación y deprecación automática.