Cuando una respuesta de inteligencia artificial no sirve, el consejo automático es «mejora el prompt». Casi nunca es ahí donde está el problema. Dos mapas sencillos para entender de qué depende de verdad una respuesta y qué hace falta para convertirla en una decisión que alguien pueda defender.
El consejo que casi nunca funciona
Alguien le pide algo a una herramienta de inteligencia artificial, recibe una respuesta que no le sirve, y escucha siempre lo mismo: necesitas mejorar el prompt.
El consejo tiene algo de verdad y mucho de pereza. Es como decirle a alguien que su fotografía salió mal porque no apretó bien el botón. Puede ser. También puede ser que hubiera poca luz, que el lente estuviera sucio, o que esa cámara no servía para ese tipo de foto.
Un prompt claro mejora una respuesta. Lo que no puede hacer es darle al modelo una capacidad que no tiene, corregir una fuente equivocada, completar información que nunca le entregamos ni garantizar que una respuesta bien redactada sea verdadera.
Conviene entender por qué. Un modelo generativo no abre un cajón donde guarda la respuesta exacta a cada pregunta: calcula qué contenido resulta plausible según los patrones que aprendió. No es un archivador; es un improvisador extraordinariamente bien leído. De ahí salen las alucinaciones, de las que ya he escrito antes y a las que le puse cifras en RAG empresarial. Un apunte de vocabulario: el perfil de riesgos del NIST prefiere llamarlas confabulaciones, porque hablar de alucinación le atribuye a una máquina una experiencia humana que no tiene. El nombre importa menos que la consecuencia: no es un defecto que se arregle escribiendo mejor, es una propiedad del mecanismo.
Para saber dónde mirar propongo dos mapas. El primero, el Triángulo de IA, explica de qué depende una respuesta. El segundo, el flujo iterativo, qué hace falta para que sirva para algo.
El Triángulo de IA
La calidad de una respuesta no vive en un solo elemento: surge de la interacción entre modelo, prompt y contexto. No es una fórmula, y no implica que cada vértice aporte un tercio del valor. Su función es recordar que cuando algo sale mal el diagnóstico tiene tres direcciones posibles, no una.
1. Modelo: la capacidad disponible
El modelo es el motor. Unos trabajan bien con lenguaje; otros entienden imágenes, ejecutan código o consultan fuentes externas. También se diferencian en precisión, costo, privacidad y en el tamaño de la ventana de contexto: cuánta información pueden tener presente a la vez, como la mesa de alguien que solo puede mirar los papeles que le caben encima. Elegir modelo no es elegir «el más nuevo»: uno no escoge un vehículo por su velocidad máxima, sino por el terreno que va a recorrer.
Para una lluvia de ideas basta un modelo rápido; para revisar un contrato o trabajar con datos de personas, las exigencias son otras. El error más común es suponer que un modelo más potente elimina la necesidad de contexto o de revisión: entender mejor una instrucción no es tener la información correcta.
2. Prompt: la tarea expresada
El prompt es cómo comunicamos qué necesitamos. No tiene que parecer un programa ni contener una lista interminable de reglas: solo tiene que reducir la ambigüedad lo suficiente. Como mínimo conviene aclarar siete cosas.
| Elemento | Qué responde |
|---|---|
| Objetivo | Qué se quiere lograr, no solo qué se quiere recibir |
| Tarea | Qué debe hacer exactamente la IA |
| Audiencia | Para quién es el resultado |
| Criterios | Qué significaría una buena respuesta |
| Restricciones | Qué no debe hacer, suponer o inventar |
| Formato | Cómo debe entregar el resultado |
| Incertidumbre | Qué debe señalar cuando le falte información |
Desliza la tabla →
«Hazme una estrategia» deja demasiadas preguntas abiertas. Una formulación mejor no necesita ser complicada: «Compara tres formas de aumentar las solicitudes de información de este negocio el próximo mes. Usa solo los datos que te voy a entregar. Para cada opción indica esfuerzo, costo, riesgo y primera prueba. Señala qué información falta antes de recomendar una.»
El error frecuente aquí es confundir longitud con calidad: un prompt largo puede ser preciso, pero también acumular contradicciones e instrucciones que compiten entre sí.
Escribir esos siete elementos cada vez es tedioso, y por eso casi nadie los escribe. Armé un Asesor de Prompts para no tener que hacerlo a mano, y expliqué cómo lo uso. Si prefiere no depender de una herramienta ajena, en el video muestro cómo construir el suyo con una gema de Gemini.
3. Contexto: la realidad con la que debe trabajar
El contexto es la información que permite adaptar la respuesta a una situación concreta: datos, documentos, antecedentes, ejemplos, definiciones internas, políticas, restricciones, audiencia, decisiones ya tomadas y —esto se olvida siempre— información que no debe usarse.
Si alguien pide «redacta una propuesta comercial», el prompt define la tarea; la empresa, el cliente, el alcance, los precios y las propuestas anteriores son el contexto. Sin él, la herramienta llena los vacíos con patrones generales: suena profesional y es genérico, o peor, incluye supuestos que nadie confirmó.
Y aquí está el matiz que casi nunca se dice: más contexto no siempre es mejor contexto. Un conjunto de documentos puede traer versiones obsoletas, cifras contradictorias o información que la persona no estaba autorizada a compartir. Un modelo que recibe dos versiones de la verdad no avisa que hay dos: elige una.
- Relevante y suficiente: no obliga a suponer.
- Actualizado y autorizado: es la versión vigente y quien la entrega puede hacerlo.
- Trazable: se sabe de dónde salió cada afirmación.
Curarlo es una competencia humana, y la más escasa de las tres. No consiste en cargar archivos: consiste en decidir cuáles son pertinentes, cuál es la fuente de verdad cuando hay varias, y qué debe quedarse afuera.
Este vértice es el más importante y el peor atendido. Hace un tiempo escribí que la IA no hace inteligente a tu empresa: solo amplifica lo que ya es. El Triángulo es la versión individual de ese mismo argumento. El modelo amplifica lo que le damos: si el contexto está desordenado, la respuesta va a estar desordenada, pero con mejor gramática. Y eso es más peligroso, porque pasa desapercibido.
En una organización el contexto deja de ser un archivo adjunto y se vuelve arquitectura: qué documentos existen, cuál es la versión vigente, quién puede verlos. Ese es exactamente el problema que desarrollé en RAG empresarial: el problema no es buscar, es permitir. El vértice del contexto es el espejo donde una empresa se ve como está, no como cree estar.
Cuando algo falla, el triángulo dice dónde mirar
El resultado está en el centro porque es la consecuencia de cómo interactúan los tres vértices. Ahí está la utilidad práctica del mapa: retroalimentar no es escribir «hazlo mejor» tres veces —eso no es retroalimentación, es esperanza—, sino detectar qué falló y corregir el componente que corresponde.
Precise el objetivo, los criterios y el formato. La herramienta hizo algo razonable con lo poco que le dijeron.
Síntoma clásico de una instrucción que describe el tema pero no la decisión que debe facilitar.
Enriquezca el contexto con la información que falta, no repita la petición.
Pedirle a la IA que «investigue más» rara vez arregla lo que sencillamente no le entregamos.
Depure y declare cuál es la fuente de verdad.
Un modelo que recibe dos versiones no avisa que hay dos: elige una, y casi nunca dice cuál.
Cambie de modelo o de herramienta.
Ningún prompt le da a un modelo una capacidad que no tiene. Este es el vértice que más se ignora.
Defina audiencia, formato y qué significa «listo».
El resultado es verdadero y aun así no sirve: falta la especificación de entrega, no la información.
Añada controles, reglas o revisión especializada.
Cuando un error reaparece, el problema ya no es la respuesta: es que nadie lo está atrapando.
Una combinación merece atención aparte: un contexto equivocado con un prompt claro y un buen modelo produce el peor resultado posible, porque produce uno que parece impecable. No hay señal de alarma. Por eso la calidad del contexto no es un detalle operativo: es un control de riesgo.
Segundo mapa: de una respuesta a un resultado
Una interacción aislada produce contenido. Un flujo bien diseñado produce una capacidad: algo que se puede repetir, revisar, medir y mejorar. Lo primero es un truco; lo segundo, una forma de trabajar.
Entrada
El proceso empieza antes de la IA. Antes de entregar información: ¿es necesaria?, ¿está vigente?, ¿tengo autorización?, ¿cuál es la fuente de verdad? Buena parte de la calidad se decide aquí.
IA
Generar no es decidir. No basta con decir «usamos IA»: hay que decir qué tarea hace ella y cuál sigue siendo humana. Puede extraer los campos de una factura mientras una regla valida los valores y una persona revisa las excepciones. Su salida es una propuesta.
Revisión humana
La etapa que más se nombra y menos se diseña. Poner a una persona después de la IA no garantiza supervisión: garantiza que hay alguien a quien culpar. La sección siguiente es sobre esto.
Salida
Una salida útil no es el texto en pantalla: es un mensaje aprobado, un informe con fuentes, una decisión documentada. Suele necesitar validación, versión, responsable y fecha.
Retroalimentación
Al usar el resultado aparece información que la conversación no tenía: si funcionó, qué corrigió el especialista, qué riesgo no vimos. Eso alimenta la siguiente iteración —o la decisión de que la IA no era el instrumento.
Estar en el flujo no es tener el control
Aquí está la parte más importante del artículo. La expresión human-in-the-loop —una persona que interviene en algún punto de un proceso automatizado— se volvió un sello de tranquilidad: se dice «hay revisión humana» y se da por resuelto el problema del control. No lo está.
Una revisión puede ser ceremonial si la persona no conoce el tema, no tiene acceso a las fuentes, dispone de segundos por caso, recibe más volumen del que puede procesar, no puede detener el proceso, o confirma por rutina porque hasta ahora casi siempre estuvo bien.
La investigación sobre sesgo de automatización —la tendencia humana a confiar de más en lo que propone una máquina— llegó incluso a la ley: el Reglamento Europeo de IA obliga a que los sistemas de alto riesgo permitan a quienes los supervisan ser conscientes de ese sesgo. Pero Johann Laux y Hannah Ruschemeier, en el European Journal of Risk Regulation, señalan lo incómodo: generar conciencia no es corregir el sesgo. Uno puede saber que tiende a confiar de más, y confiar de más igual.
Una persona está realmente en control cuando puede comprender para qué existe el sistema, acceder a la evidencia y no solo al resultado, disponer del tiempo suficiente para detectar un error, pedir otra iteración, rechazar la recomendación sin costo personal, detener el proceso y asumir con nombre propio la responsabilidad de la decisión. Si falta la mitad de esa lista, lo que hay es una firma, no una supervisión.
Y cuando revisa, cinco preguntas sirven para casi cualquier caso: si los hechos —datos, cálculos, nombres y fuentes— son correctos; si el resultado sirve al propósito o solo se parece a lo que se pidió; qué información importante falta o se está dando por supuesta; qué riesgo hay para las personas; y qué consecuencias tiene usarlo y quién debe autorizarlo.
Hay una consecuencia de esto que casi no se discute y que creo que será el problema central de la adopción de IA en los próximos años. La formulo así: la revisión humana no es un paso, es un presupuesto. Un presupuesto de atención experta, que es el recurso más escaso e inelástico de cualquier organización. No se compra por suscripción.
La IA multiplica la producción de contenido y de propuestas con una facilidad sin precedentes. La capacidad de revisarlas crece al ritmo lento al que se forma un buen criterio. Cuando la primera curva se dispara y la segunda no se mueve, la diferencia no desaparece: se acumula. A eso lo llamo deuda de revisión, por analogía con la deuda técnica. Al principio no se siente. Se paga después, con errores que nadie detectó a tiempo.
En Alfabetización en IA: no es saber prompts, es saber juzgar propuse una matriz para decidir qué delegar, qué cocrear y qué proteger. La deuda de revisión es su razón económica: si todo se delega, todo hay que revisarlo, y no alcanza. La pregunta de gestión no es cuánto puede producir su equipo con IA. Es cuánto puede revisar.
Cuánto control necesita cada caso
Si la atención es un presupuesto, la pregunta deja de ser «¿revisamos o no?» y pasa a ser «¿dónde gastamos la revisión?». Depende de dos variables: qué tan grave es equivocarse y cuántos casos hay. Este cuadro es mío y ordena la conversación en cinco minutos.
Revisión completa
Un experto revisa cada caso, firma y queda registro.
Contrato, decisión de crédito, apoyo a un diagnósticoRediseñar antes de escalar
Reglas deterministas antes del modelo y revisión por excepción. Si no se puede, no usar IA.
Selección masiva de candidatos, priorización de pacientesVerificación ligera
Quien produce revisa. Sin proceso formal.
Borrador interno, lluvia de ideasMuestreo y alertas
Se revisa una fracción y se mide la tasa de error.
Clasificación de tickets de soporteVolumen de casos →
Matriz de proporcionalidad del control. Elaboración propia. Es un marco de decisión, no una medición.
El rojo —consecuencias irreversibles y alto volumen— es donde más se quiere usar IA y donde peor funciona la revisión humana, precisamente porque el volumen impide revisar bien. La respuesta correcta casi nunca es «contratamos más revisores». Es cambiar el diseño: convertir parte del problema en reglas que se cumplen siempre, reducir el volumen que llega al modelo, o aceptar que ese caso todavía no es para IA.
No todo lo que llaman agente necesita IA
El cuadrante rojo esconde una pregunta que casi siempre llega tarde: ¿este caso necesitaba IA?
Es la conversación que más se repite en mi trabajo de consultoría. Una empresa quiere un agente de inteligencia artificial y, cuando uno pide que describa la tarea, resulta ser siempre la misma: llega un archivo igual todos los lunes, hay que mover cuatro campos a otro sistema y avisar por correo. Eso no es un problema de IA: es un problema de automatización, y llevaba años esperando a que alguien lo mirara.
Poner IA ahí es como pagarle a un abogado por hora para que llene un formulario. Puede hacerlo, y lo hará bien. Pero está gastando una capacidad cara —interpretar ambigüedad, decidir con criterio— en una tarea que no tiene ninguna ambigüedad que interpretar. Y encima habrá que revisar lo que hizo.
Distinguir cuatro piezas evita la mitad de las implementaciones confusas:
IA
Interpretar ambigüedad: generar, clasificar, resumir, extraer, proponer.
Cuesta: se paga por uso, y además hay que revisar cada salida.Automatización
Mover información y ejecutar pasos definidos, siempre igual.
Cuesta: se construye una vez; después es casi gratis.Reglas
Validar condiciones que deben cumplirse sin excepción.
Cuesta: poco, y son auditables; hay que mantenerlas cuando el negocio cambia.Sistema de trabajo
Integrar personas, datos, tecnología, controles y métricas.
Cuesta: tiempo y decisiones, no licencias. Es donde vive el valor y donde casi nadie invierte.Y cuatro preguntas bastan para ubicar una tarea antes de elegir la herramienta:
- ¿Hay ambigüedad que alguien deba interpretar? Si la respuesta siempre se deduce de los datos, es una regla.
- ¿La entrada llega distinta cada vez? Si llega siempre igual, es automatización.
- ¿Necesito que el resultado sea idéntico en cada ejecución? La IA no lo garantiza; una regla sí.
- ¿Puedo escribir el procedimiento paso a paso y sin excepciones? Entonces ya lo resolvió: solo falta ejecutarlo.
Y hay un argumento de costo que casi siempre se queda fuera de la hoja de cálculo. Se compara el precio del modelo contra el de una automatización y la IA no sale tan mal parada. Pero el precio del modelo no es el costo total: cada salida de IA que entra a un proceso añade una revisión, y una regla determinista no añade ninguna. Es la deuda de revisión en su forma más concreta. Una automatización que funciona se olvida; una IA que funciona hay que seguir mirándola.
Nada de esto es un argumento contra la IA, sino a favor de gastarla donde rinde: en las tareas que sí tienen ambigüedad, criterio y variedad. Cuando se usa para todo, la organización paga dos veces —el modelo y la revisión— por resultados que un formulario habría entregado gratis y siempre iguales.
Qué significa esto en una empresa
El AI Index 2026 de Stanford reporta que el 88 % de las organizaciones consultadas usaba IA en al menos una función de negocio en 2025 —eran 78 % en 2024— y que el 79 % usaba IA generativa con regularidad. Al mismo tiempo, en agentes, la mayoría reportó no usarlos en absoluto y el uso a escala se quedó en un solo dígito en casi todas las funciones.
No se contradicen: miden cosas distintas. El 88 % mide acceso —alguien abrió una herramienta—. El dígito único mide rediseño —alguien cambió cómo se hace el trabajo—. Entre las dos está todo lo que este artículo llama flujo.
Hay un dato de la OCDE que debería cerrar la discusión sobre qué hay que aprender: menos del 1 % de los trabajadores necesita habilidades avanzadas de IA. La mayoría necesita habilidades digitales y capacidad de usar e interpretar datos. El mismo informe encuentra que el 40 % de los empleadores de manufactura y finanzas que aún no adoptan IA dice que las habilidades son la razón principal.
El artículo 4 del Reglamento Europeo de IA obliga a proveedores y organizaciones usuarias a desarrollar la alfabetización en IA de su personal. Entró en aplicación en febrero de 2025, pero las reglas de supervisión y sanción aplican desde el 3 de agosto de 2026. La Comisión insiste en que no hay talla única: la formación se adapta al conocimiento previo, al contexto de uso y al riesgo. Si opera en Europa o vende allá, dejó de ser una recomendación.
Sobre productividad, el estudio más citado se publicó en The Quarterly Journal of Economics: un asistente conversacional entre 5.172 agentes de servicio al cliente aumentó en promedio un 15 % los casos resueltos por hora. El matiz casi nunca se cita: los de menos experiencia mejoraron velocidad y calidad, mientras que los más experimentados ganaron poca velocidad y perdieron algo de calidad. El promedio esconde dos efectos opuestos.
El Triángulo se compra: modelo, prompt y contexto están al alcance de cualquiera con una tarjeta de crédito. El flujo se construye, y construirlo es aburrido —entradas definidas, criterios escritos, revisión asignada, medición antes y después—. Esa asimetría explica el 88 % conviviendo con un dígito único.
Dónde la evidencia es floja
Esta sección es la que casi nadie escribe. Aquí está lo que estos marcos no permiten afirmar —incluidos los míos.
El Triángulo de IA es un marco pedagógico, no una ecuación validada: los tres vértices no explican todo el desempeño de un sistema ni aportan el mismo porcentaje al resultado. Lo mismo aplica a la deuda de revisión: es una analogía mía, útil para pensar, sin medición detrás. No conozco un estudio que cuantifique esa brecha en organizaciones reales. Hasta que alguien lo haga, es una hipótesis, no un hallazgo.
| Afirmación | Calidad del soporte | Con qué precaución leerla |
|---|---|---|
| La IA generativa puede producir contenido falso convincente | Alta · marco de un organismo de estándares | La frecuencia depende del modelo, la tarea y las herramientas |
| La supervisión humana puede sufrir sesgo de automatización | Alta · literatura consolidada y reconocimiento regulatorio | La magnitud depende del diseño del puesto, no solo de la persona |
| Modelo, prompt y contexto explican la calidad | Conceptual · elaboración propia | Marco pedagógico, no una relación medida |
Desliza la tabla →
Dos advertencias: el 15 % del Quarterly Journal of Economics es un promedio que esconde efectos opuestos, y las cifras de adopción vienen de encuestas a ejecutivos. Me harían cambiar de conclusión: modelos con confiabilidad verificable en tareas abiertas, evidencia de que alguna intervención reduce de verdad el sesgo de automatización, y cualquier medición seria de la brecha entre producir y revisar.
Saber pedir no es saber dirigir
La IA está dejando de ser una herramienta especializada para convertirse en infraestructura cotidiana. La pregunta importante no es quién conoce más prompts: es quién comprende mejor el sistema. Los dos mapas caben en dos líneas:
Revisión + decisión + retroalimentación la convierten en aprendizaje y valor.
Y si algo debería quedar, no es el triángulo ni el flujo. Es haber notado que la parte más frágil del sistema no es el modelo: es el momento —casi siempre breve y casi nunca diseñado— en que una persona mira lo que la máquina propuso y decide si lo usa. Esa persona necesita tiempo, evidencia, criterio y permiso para decir que no. Si su organización no le da esas cuatro cosas, no tiene supervisión humana. Tiene una firma.
Preguntas frecuentes
¿Cuál de los tres vértices es el más importante?
¿Todo resultado de IA necesita que una persona lo revise?
¿Cómo sé si necesito IA o me basta con una automatización?
¿Se puede usar IA para revisar IA?
¿Qué es la deuda de revisión?
Fuentes y lecturas
En este blog
- La IA no hace inteligente a tu empresa: solo amplifica lo que ya es
- Alfabetización en IA: no es saber prompts, es saber juzgar
- RAG empresarial: el problema no es buscar, es permitir
- AI-Native no es tener más IA: es aprender a rediseñar el trabajo
- Analítica de datos en 5 niveles
- PULSE: decidir mejor con datos
Marcos, normas y evidencia
- NIST — Generative Artificial Intelligence Profile (NIST AI 600-1) y el AI Risk Management Framework
- UNESCO — AI Competency Framework for Students y la Recomendación sobre la Ética de la IA
- Comisión Europea — Alfabetización en IA: preguntas y respuestas (artículo 4 del Reglamento de IA)
- Stanford HAI — AI Index Report 2026, capítulo de Economía
- OCDE — AI and Skills: What We Know So Far (2026)
- Brynjolfsson, Li y Raymond — Generative AI at Work, The Quarterly Journal of Economics (2025)
- Laux y Ruschemeier — Automation Bias in the AI Act, European Journal of Risk Regulation (2025)
¿Su equipo tiene un flujo, o solo una herramienta?
Si quiere revisar cómo está diseñado el flujo de IA en su equipo —entradas, criterios, revisión y medición— podemos conversarlo.
Escribir por WhatsAppNota de transparencia. Este artículo fue escrito con asistencia de inteligencia artificial en la investigación, la estructura y la redacción. Todas las cifras fueron contrastadas contra la fuente original. Los marcos propios —el Triángulo de IA, la matriz de proporcionalidad del control y el concepto de deuda de revisión— son elaboración del autor, quien asume la responsabilidad final del contenido. Es, en sí mismo, un ejemplo del flujo que describe.
The Prompt Is Not the Problem: Two Maps for Using AI with Judgment
When an AI answer falls short, the advice is always the same: “write a better prompt.” That is almost never where the problem lies. Two simple maps for understanding what an answer really depends on, and what it takes to turn one into a decision somebody can defend.
The advice that rarely works
Someone asks an AI tool for something, gets back an answer that does not help, and hears the same thing every time: you need a better prompt.
There is some truth in that advice, and a great deal of laziness. It is like telling someone their photograph came out badly because they did not press the button properly. Maybe. It could also be that the light was poor, the lens was dirty, or that the camera simply was not built for that kind of shot.
A clear prompt improves an answer. What it cannot do is give a model a capability it does not have, correct a wrong source, fill in information we never provided, or guarantee that a well-written answer is true.
It helps to understand why. A generative model does not open a drawer holding the exact answer to each question: it calculates what content is plausible given the patterns it learned. It is not a filing cabinet; it is an extraordinarily well-read improviser. That is where hallucinations come from—something I have written about before and put numbers to in Enterprise RAG (in Spanish). One point of vocabulary is worth making: the NIST risk profile prefers to call them confabulations, because the word hallucination credits a machine with an experience it does not have. The name matters less than the consequence: this is not a defect you fix by writing better; it is a property of the mechanism.
To know where to look, I offer two maps. The first, the AI Triangle, explains what an answer depends on. The second, the iterative flow, explains what it takes to turn that answer into something useful.
The AI Triangle
The quality of an answer does not live in a single element: it emerges from the interaction between model, prompt and context. It is not a formula, and it does not imply that each vertex contributes a third of the value. Its job is to remind us that when something goes wrong, the diagnosis can point in three directions, not one.
1. Model: the available capability
The model is the engine. Some models handle language especially well; others understand images, run code or consult external sources. They also differ in accuracy, cost, privacy and the size of the context window: how much information they can hold in view at once, like the desk of someone who can only look at the papers that fit on it. Choosing a model is not choosing “the newest”: you do not pick a vehicle by its top speed but by the terrain you will cross.
For brainstorming, a fast model is plenty; for reviewing a contract or handling people’s data, the requirements are different. The most common mistake is to assume that a more powerful model removes the need for context or review: understanding an instruction better is not the same as having the right information.
2. Prompt: the task expressed
The prompt is how we communicate what we need. It does not have to read like a program or carry an endless list of rules; it only has to remove enough ambiguity. At a minimum, seven things are worth spelling out.
| Element | What it settles |
|---|---|
| Objective | What you want to achieve, not just what you want to receive |
| Task | What exactly the AI should do |
| Audience | Who the result is for |
| Criteria | What would count as a good answer |
| Constraints | What it must not do, assume or invent |
| Format | How the result should be delivered |
| Uncertainty | What it should flag when information is missing |
Swipe the table →
“Build me a strategy” leaves far too many questions open. A better version does not have to be complicated: “Help me compare three ways to increase the number of inquiries this business receives next month. Use only the data I am about to give you. For each option, state the effort, the cost, the risk and a first test to run. Flag anything you are missing before you recommend one.”
The common mistake here is to confuse length with quality: a long prompt can be precise, but it can just as easily pile up contradictions and instructions that pull against each other.
Writing out those seven elements every time is tedious, which is why hardly anyone does it. I built a Prompt Advisor so I would not have to do it by hand, and wrote up how I use it. If you would rather not depend on someone else’s tool, the video walks through building your own with a Gemini gem.
3. Context: the reality it has to work with
Context is the information that lets you tailor an answer to a specific situation: data, documents, background, examples, internal definitions, policies, constraints, audience, decisions already made and—this one is always forgotten—information that must not be used.
If someone asks for “a commercial proposal,” the prompt defines the task; the company, the client, the scope, the pricing and previous proposals are the context. Without it, the tool fills the gaps with generic patterns: the result sounds professional and says nothing, or worse, rests on assumptions nobody ever confirmed.
And here is the nuance nobody mentions: more context is not always better context. A folder of documents can contain superseded versions, contradictory figures, or material the person was never authorized to share. A model handed two versions of the truth does not flag that there are two: it picks one.
- Relevant and sufficient: nobody has to guess.
- Current and authorized: the version that is actually in use, from someone entitled to share it.
- Traceable: you know where each claim came from.
Curating context is a human skill, and the scarcest one the triangle demands. It is not a matter of uploading files: it is deciding which ones are relevant, which one is the source of truth when several compete, and what has to stay out.
This vertex is the most important one, and the most neglected. Some time ago I wrote that AI does not make your company intelligent: it only amplifies what it already is (in Spanish). The Triangle is the individual version of that same argument. The model amplifies whatever we hand it: if the context is a mess, the answer will be a mess too, only with better grammar. That is the more dangerous outcome, because nobody notices.
In an organization, context stops being an attachment and becomes architecture: which documents exist, which version is current, who is allowed to see them. That is exactly the problem I took up in Enterprise RAG: the problem is not search, it is permission (in Spanish). The context vertex is the mirror in which a company sees itself as it is, not as it believes it is.
When something fails, the triangle tells you where to look
The result sits at the center because it is the consequence of how the three vertices interact. That is what makes the map useful: giving feedback is not typing “do it better” three times—that is not feedback, that is hope—but working out what failed and fixing the component responsible.
Sharpen the objective, the criteria and the format. The tool did something reasonable with the little it was told.
The classic symptom of an instruction that describes the topic but not the decision it should support.
Enrich the context with what is missing; do not repeat the request.
Asking the AI to “look into it further” rarely fixes what we simply never gave it.
Prune them and declare which is the source of truth.
A model that receives two versions does not warn you there are two: it picks one, and rarely says which.
Switch to a different model or tool.
No prompt gives a model a capability it does not have. This is the vertex people ignore most.
Define the audience, the format and what “done” means.
The output is true and still useless: what is missing is the delivery spec, not the information.
Add controls, rules or specialist review.
When an error comes back, the problem is no longer the answer: it is that nobody is catching it.
One combination deserves a moment of its own: the wrong context, with a clear prompt and a good model, produces the worst possible outcome—because it produces one that looks flawless. Nothing trips an alarm. That is why the quality of the context is not an operational detail: it is a risk control.
Second map: from an answer to a result
A one-off interaction produces content. A well-designed flow produces a capability: something that can be repeated, reviewed, measured and improved. The first is a party trick; the second is a way of working.
Input
The process starts before the AI does. Before handing over any information, ask: Is it necessary? Is it current? Am I authorized to use it? Which version is the source of truth? A large share of the quality is settled right here.
AI
Generating is not deciding. Saying “we use AI” is not enough: you have to say which task it handles and which one stays human. It can pull the fields from an invoice while a rule checks that the numbers add up and a person handles the exceptions. What it returns is a proposal.
Human review
The stage everyone names and almost nobody designs. Putting a person after the AI does not guarantee oversight; it guarantees there is someone to blame. The next section is about exactly this.
Output
A useful output is not the text that appeared on screen. It is an approved message, a report with its sources, a documented decision. Getting there usually takes validation, a version number, an owner and a date.
Feedback
Using the result surfaces information the conversation never had: whether it worked, what the specialist corrected, which risk we missed. That feeds the next iteration—or the decision that AI was the wrong instrument for the job.
Being in the loop is not being in control
This is the most important part of the article. The phrase human-in-the-loop—a person who steps in at some point in an automated process—has become a badge of reassurance: people say “there is human review” and consider the control problem solved. It is not.
A review can be purely ceremonial. It happens whenever the reviewer does not know the subject, cannot get at the sources, has seconds per case, receives more volume than they can absorb, or has no power to halt the process. It also happens when they sign off out of habit, because so far the system has almost always been right.
Research on automation bias—the human tendency to over-rely on what a machine proposes—has even reached the law: the EU AI Act requires high-risk systems to keep the people overseeing them aware of that bias. But Johann Laux and Hannah Ruschemeier, in the European Journal of Risk Regulation, point to the uncomfortable part: creating awareness is not correcting the bias. One can know one tends to over-trust, and over-trust anyway.
Someone is genuinely in control when they understand why the system exists, can see the evidence and not just the result, and have the time to catch an error. They can also ask for another iteration, change the context or the model, turn the recommendation down without paying a personal price, stop the process, and put their name to the decision. If half of that list is missing, what you have is a signature, not oversight.
And when reviewing, five questions cover almost any case. Are the facts—data, calculations, names and sources—correct? Does the result serve the purpose, or does it merely resemble what was asked for? What important information is missing or being assumed? What is the risk to people? And what happens if we use it—who has to authorize that?
There is a consequence of all this that hardly anyone discusses, and that I think will be the central problem of AI adoption over the next few years. I would put it like this: human review is not a step; it is a budget. A budget of expert attention—the scarcest and least elastic resource any organization has. It does not come with a subscription.
AI multiplies output—content, drafts, proposals—with unprecedented ease. The capacity to review that output grows at the slow pace at which good judgment forms. When the first curve takes off and the second barely moves, the gap does not close: it compounds. I call it review debt, by analogy with technical debt. At first it costs nothing. You pay it later, in errors nobody caught in time.
In AI literacy: it is not knowing prompts, it is knowing how to judge (in Spanish) I proposed a matrix for deciding what to delegate, what to co-create and what to protect. Review debt is the economics behind that matrix: if everything is delegated, everything has to be reviewed, and the capacity is not there. The management question is not how much your team can produce with AI. It is how much it can review.
How much control each case needs
If attention is a budget, the question is no longer “do we review or not?” but “where do we spend it?” That turns on two variables: how bad a mistake would be, and how many cases there are. This grid is my own, and it usually organizes the conversation in about five minutes.
Full review
An expert reviews every case, signs off, and it is logged.
Contract, credit decision, diagnostic supportRedesign before scaling
Deterministic rules before the model, and review by exception. If that is not feasible, do not use AI.
Mass candidate screening, patient prioritizationLight verification
Whoever produces it reviews it. No formal process.
Internal draft, brainstormingSampling and alerts
Review a fraction and measure the error rate.
Support ticket triageCase volume →
Control proportionality matrix. Author’s own work. It is a decision framework, not a measurement.
The red one—irreversible consequences, high volume—is where people most want to use AI and where human review works worst, precisely because the volume makes proper review impossible. The right answer is almost never “hire more reviewers.” It is to change the design: turn part of the problem into rules that always hold, cut the volume that reaches the model, or accept that this case is not ready for AI.
Not everything called an agent needs AI
The red quadrant hides a question that almost always comes too late: did this case need AI at all?
It is the conversation I have most often in my consulting work. A company wants an AI agent, and when you ask them to describe the task, it turns out to be the same one every time: an identical file lands every Monday, four fields have to move to another system, and someone has to be emailed. That is not an AI problem. It is an automation problem, and it had been sitting there for years waiting for someone to look at it.
Putting AI on that is like paying a lawyer by the hour to fill out a form. They can do it, and they will do it well. But you are spending an expensive capability—interpreting ambiguity, exercising judgment—on a task that contains no ambiguity at all. And on top of that, someone still has to check the work.
Keeping these four things distinct heads off half the muddled implementations I have seen:
AI
Interpreting ambiguity: generating, classifying, summarizing, extracting, proposing.
Costs: paid per use, plus reviewing every output.Automation
Moving information and executing defined steps, always the same way.
Costs: built once; after that it is nearly free.Rules
Validating conditions that must hold without exception.
Costs: little, and they are auditable; they have to be maintained when the business changes.Work system
Integrating people, data, technology, controls and metrics.
Costs: time and decisions, not licenses. Where the value lives, and where almost nobody invests.And four questions are usually enough to place a task before you pick the tool:
- Is there ambiguity that someone has to interpret? If the answer always follows from the data, you want a rule.
- Does the input arrive differently each time? If it always looks the same, you want automation.
- Do you need the result to be identical on every run? AI cannot guarantee that; a rule can.
- Can you write the procedure out step by step, with no exceptions? Then you have already solved it. All that is left is to run it.
And there is a cost argument that almost never makes it onto the spreadsheet. People line up the price of the model against the price of an automation, and AI does not come off badly. But the price of the model is not the total cost: every AI output that enters a process adds a review, and a deterministic rule adds none. That is review debt in its most concrete form. An automation that works gets forgotten; an AI that works has to be watched.
None of this is an argument against AI. It is an argument for using it where it earns its keep: on the tasks that genuinely involve ambiguity, judgment and variety. Use it for everything and the organization pays twice—once for the model, once for the review—for results a plain form would have delivered for free, and identically every time.
What this means inside a company
The 2026 Stanford AI Index reports that 88% of surveyed organizations used AI in at least one business function in 2025—up from 78% in 2024—and that 79% regularly used generative AI. At the same time, when it came to agents, a majority reported no use at all, and scaled use stayed in the single digits across nearly every function.
The two figures do not contradict each other; they measure different things. The 88% measures access: someone opened a tool. The single digit measures redesign: someone changed how the work gets done. Everything this article calls the flow sits between the two.
One figure from the OECD ought to settle the debate about what actually has to be learned: fewer than 1% of workers need advanced AI skills. Most need digital skills and the ability to use and interpret data. The same report finds that 40% of employers in manufacturing and finance who have not yet adopted AI name skills as the main reason.
Article 4 of the EU AI Act requires providers and deployers to build the AI literacy of their staff. It entered into application in February 2025, but supervision and enforcement rules apply from 3 August 2026. The Commission is clear that there is no one-size-fits-all: training has to match people’s prior knowledge, the context of use and the risk of the system. If you operate in Europe or sell into it, this has stopped being a recommendation.
On productivity, the most cited study appeared in The Quarterly Journal of Economics: rolling out a conversational assistant to 5,172 customer-support agents raised issues resolved per hour by 15% on average. The nuance almost never gets quoted: less experienced workers improved both speed and quality, while the most experienced gained little speed and lost a little quality. The average conceals two opposing effects.
The Triangle can be bought: model, prompt and context are available to anyone with a credit card. The flow has to be built, and building it is dull work—defined inputs, written criteria, named reviewers, measurement before and after. That asymmetry is why 88% sits so comfortably alongside a single digit.
Where the evidence is thin
This is the section almost nobody bothers to write. Here is what these frameworks do not let us claim—mine included.
The AI Triangle is a teaching framework, not a validated equation: the three vertices do not account for everything a system does, and they do not contribute equal shares of the result. The same goes for review debt: it is my own analogy, useful for thinking with, and there is no measurement behind it. I know of no study that quantifies the gap in real organizations. Until someone runs one, this is a hypothesis, not a finding.
| Claim | Strength of support | How to read it carefully |
|---|---|---|
| Generative AI can produce convincing false content | High · standards body framework | Frequency depends on the model, the task and the tools |
| Human oversight can suffer automation bias | High · established literature and regulatory recognition | Magnitude depends on job design, not just the person |
| Model, prompt and context explain quality | Conceptual · author’s own framework | A pedagogical framework, not a measured relationship |
Swipe the table →
Two warnings. The 15% from the Quarterly Journal of Economics is an average that conceals opposing effects, and the adoption figures come from surveys of executives. What would change my conclusion: models with verifiable reliability on open-ended tasks; evidence that some specific intervention genuinely reduces automation bias; and any serious measurement of the gap between producing and reviewing.
Knowing how to ask is not knowing how to steer
AI is turning from a specialist tool into everyday infrastructure. The question that matters is not who knows the most prompts; it is who understands the system best. Both maps fit into two lines:
Review + decision + feedback turn it into learning and value.
And if one thing should stay with you, it is neither the triangle nor the flow. It is the realization that the most fragile part of the system is not the model. It is the moment—almost always brief, almost never designed—when a person looks at what the machine proposed and decides whether to use it. That person needs time, evidence, judgment, and permission to say no. If your organization does not give them all four, it does not have human oversight. It has a signature.
Frequently asked questions
Which of the three vertices matters most?
Does every AI output need a person to review it?
How do I know whether I need AI or just an automation?
Can AI be used to review AI?
What is review debt?
Sources and further reading
On this blog
- AI does not make your company intelligent: it only amplifies what it already is (in Spanish)
- AI literacy: it is not knowing prompts, it is knowing how to judge (in Spanish)
- Enterprise RAG: the problem is not search, it is permission (in Spanish)
- AI-Native is not having more AI: it is learning to redesign work (in Spanish)
- Data analytics in 5 levels (in Spanish)
- PULSE: deciding better with data (in Spanish)
Frameworks, rules and evidence
- NIST — Generative Artificial Intelligence Profile (NIST AI 600-1) and the AI Risk Management Framework
- UNESCO — AI Competency Framework for Students and the Recommendation on the Ethics of AI
- European Commission — AI Literacy: Questions and Answers (Article 4 of the AI Act)
- Stanford HAI — 2026 AI Index Report, Economy chapter
- OECD — AI and Skills: What We Know So Far (2026)
- Brynjolfsson, Li and Raymond — Generative AI at Work, The Quarterly Journal of Economics (2025)
- Laux and Ruschemeier — Automation Bias in the AI Act, European Journal of Risk Regulation (2025)
Does your team have a flow, or just a tool?
If you would like to look at how the AI flow in your team is designed—inputs, criteria, review and measurement—let’s talk.
Message on WhatsAppTransparency note. This article was written with AI assistance in research, structure and drafting. Every figure was checked against its original source. The frameworks it introduces—the AI Triangle, the control proportionality matrix and the idea of review debt—are the author’s own, and the author takes final responsibility for the content. It is, in itself, an example of the flow it describes. This English version is a localization of the Spanish original.
Deja un comentario