Este es el pilar que define el sistema. Si quieres la crítica operativa al prompt engineering, revisa el derivado: Por que prompt engineering no escala negocio.
Problema
Prompt engineering resuelve síntomas locales, no arquitectura.
Un equipo puede conseguir respuestas “aceptables” con prompts cada vez mas largos, pero ese enfoque colapsa cuando aparecen mas casos de uso, mas personas editando instrucciones y mas fuentes de verdad compitiendo entre si.
Tesis
Escalar IA exige diseñar contexto antes que prompts.
Un buen prompt no reemplaza una mala base de conocimiento. Solo la disfraza durante un tiempo.
Framework: Context Architecture
Capa 1: Modelo de conocimiento
Define que fuentes son canonicas para cada decisión:
- políticas
- procedimientos
- datos operativos
- criterios de riesgo
Cada fuente debe tener owner y versión.
Capa 2: Contrato de recuperación
No todo el contenido debe entrar en cada respuesta.
Debes definir:
- que se recupera por tipo de consulta
- que queda fuera
- que umbral de confianza obliga escalado a humano
Capa 3: Evaluación continua
Sin evaluación, cualquier sistema deriva.
Necesitas pruebas recurrentes sobre:
- factualidad
- consistencia
- utilidad para el rol que ejecuta
Caso (anon): una empresa de servicios tenia tres equipos lanzando asistentes sobre documentos internos distintos. El resultado eran respuestas correctas en demos, pero contradictorias en operación diaria. Al definir fuentes canonicas por decisión, versionar contexto y fijar umbrales de escalado, bajo la variabilidad sin cambiar modelo.
De prompt craft a decisión infrastructure
Un prompt puede mejorar presentación. Context Architecture mejora fiabilidad. La diferencia operativa es crítica:
- el prompt vive en la interfaz,
- el contexto vive en el sistema,
- la decisión ocurre en negocio.
Si optimizas solo la interfaz, las inconsistencias vuelven en cuanto cambia el equipo, el caso de uso o la fuente de datos.
Contrato mínimo por caso de uso
Cada flujo productivo debería declarar explicitamente:
- objetivo de decisión: que resultado habilita esta respuesta,
- fuentes permitidas: que corpus puede usarse y con que prioridad,
- umbral de confianza: cuando debe escalar a humano,
- owner de conocimiento: quien mantiene cada fuente.
Sin contrato, el sistema improvisa. Y un sistema que improvisa no escala con control.
Taxonomía de errores para mejorar de verdad
No todos los fallos son “alucinaciones”. En práctica suelen caer en cuatro tipos:
- fuente ausente: la información no estaba disponible,
- fuente contradictoria: había versiones distintas sin jerarquia,
- retrieval deficiente: se recupero contexto irrelevante,
- decisión ambigua: no estaba claro que salida era útil para ese rol.
Etiquetar así los errores permite corregir arquitectura, no solo prompt wording.
Cadencia de gobierno recomendada
Una rutina mínima quincenal debería incluir:
- muestreo de consultas reales por flujo,
- análisis de errores por taxonomía,
- decisiones de versionado de fuentes,
- ajuste de umbrales de escalado.
Si no existe esta cadencia, la calidad depende de heroismo individual.
Señales de madurez de contexto
- baja el tiempo medio de revisión humana,
- disminuyen respuestas contradictorias entre equipos,
- sube reutilización de respuestas en operaciones recurrentes,
- cae el número de prompts “parche” por caso.
Cuando esas señales mejoran a la vez, ya no tienes prompt engineering aislado: tienes arquitectura de decisión.
Postura: Esto no es un proyecto de prompts ni una compra de herramientas; sin gobierno real es teatro.
Respiración: En organizaciones reales, el dolor no es el modelo: es quién puede decir no y apagar un caso de uso.
Protocolo operativo (3 pasos)
- Inventaria fuentes activas por caso de uso y elimina duplicados conflictivos.
- Define para cada flujo un “context packet” mínimo: 3-5 bloques de información validada.
- Ejecuta un ciclo quincenal de evaluación con 15 consultas reales y plan de corrección.
Señales de que vas bien
- menos excepciones por respuesta contradictoria
- menor tiempo de revisión humana
- mayor reutilización de respuestas en operaciones recurrentes
Anti-patrones
- confiar en memoria conversacional como repositorio
- mezclar conocimiento normativo y opinion en el mismo bloque
- cambiar prompts cada semana sin control de versiones
Relacionado:
- Por que prompt engineering no escala negocio
- Human-in-the-Loop Debt: cuando tu control de calidad destruye margen
- AI Governance Sprint (14 días): del caos de casos de uso al sistema operativo
Cierre
El prompt es una interfaz. El contexto es el sistema. Si quieres resultados robustos, disena la arquitectura que sostiene la respuesta.
Si necesitas aterrizarlo en tu stack actual, podemos hacerlo en advisory o en un diagnóstico.