Este es el pilar que define el sistema. Si quieres la critica operativa al prompt engineering, revisa el derivado: Por que prompt engineering no escala negocio.
Problema
Prompt engineering resuelve sintomas 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 disenar 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 decision:
- politicas
- procedimientos
- datos operativos
- criterios de riesgo
Cada fuente debe tener owner y version.
Capa 2: Contrato de recuperacion
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: Evaluacion continua
Sin evaluacion, 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 operacion diaria. Al definir fuentes canonicas por decision, versionar contexto y fijar umbrales de escalado, bajo la variabilidad sin cambiar modelo.
De prompt craft a decision 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 decision 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 minimo por caso de uso
Cada flujo productivo deberia declarar explicitamente:
- objetivo de decision: 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.
Taxonomia de errores para mejorar de verdad
No todos los fallos son “alucinaciones”. En practica suelen caer en cuatro tipos:
- fuente ausente: la informacion no estaba disponible,
- fuente contradictoria: habia versiones distintas sin jerarquia,
- retrieval deficiente: se recupero contexto irrelevante,
- decision ambigua: no estaba claro que salida era util para ese rol.
Etiquetar asi los errores permite corregir arquitectura, no solo prompt wording.
Cadencia de gobierno recomendada
Una rutina minima quincenal deberia incluir:
- muestreo de consultas reales por flujo,
- analisis de errores por taxonomia,
- 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 revision humana,
- disminuyen respuestas contradictorias entre equipos,
- sube reutilizacion de respuestas en operaciones recurrentes,
- cae el numero de prompts “parche” por caso.
Cuando esas señales mejoran a la vez, ya no tienes prompt engineering aislado: tienes arquitectura de decision.
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” minimo: 3-5 bloques de informacion validada.
- Ejecuta un ciclo quincenal de evaluacion con 15 consultas reales y plan de correccion.
Senales de que vas bien
- menos excepciones por respuesta contradictoria
- menor tiempo de revision humana
- mayor reutilizacion 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 dias): 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 diagnostico.