La reunión duró cuarenta minutos. Al final, el director de producto lo cerró con una frase: "entonces montamos un agente que conteste con nuestra documentación y que no se invente nada, para el sprint que viene".
Todo el mundo asintió. Yo también asentí, y ese fue mi error.
En esa frase había tres proyectos distintos, un criterio de aceptación imposible de cumplir y una fecha. Lo que aprendí ese trimestre es que explicar IA a negocio no es un favor que le haces a tu jefe: es una tarea técnica que, si no haces, la pagas tú.
Resumen rápido
Explicar IA a negocio no consiste en corregir términos: consiste en convertir cada frase de la reunión en una decisión escrita antes de que llegue al sprint como alcance. Seis frases hacen casi todo el daño: "es solo un prompt", "necesitamos un agente", "entrénalo con nuestros datos", "que no alucine", "con IA iremos mucho más rápido" y "¿esto ya está en producción?". El método son cuatro pasos: traduce a decisión y no a definición, pon el tradeoff con números aunque sean aproximados, deja la decisión escrita y pelea el alcance en lugar de la palabra.
El malentendido no se queda en la reunión: acaba en el alcance de tu sprint
Cuando alguien de negocio usa mal un término técnico, tú y yo hacemos lo mismo: dejarlo pasar. No es el momento, se entiende por el contexto.
El problema es que en proyectos de IA los términos no son adorno. Son alcance.
"Agente" no describe una feature: describe un sistema con permisos y modos de fallo propios. "Que no alucine" no es un requisito: es una promesa que nadie puede firmar. Y las dos acaban redactadas como criterios de aceptación por alguien que no tenía por qué saber lo que esas dos palabras arrastran.
Heredas el malentendido convertido en alcance. Y el alcance, a diferencia de la palabra, tiene fecha.
Las definiciones limpias están en el diccionario de términos de IA y puedes mandar ahí a quien pregunte. Aquí van las seis frases y la factura que te llega cuando nadie las traduce.
Traducir IA a negocio: las seis frases y lo que cuestan
Estas son las seis frases que más veces he oído en reuniones de proyecto de IA, lo que cree quien las dice y la factura concreta que llega al sprint:
| Lo que dice | Lo que cree que significa | Lo que te llega al sprint |
|---|---|---|
| "Es solo un prompt" | Una frase bien escrita, medio día | La estimación dividida entre tres |
| "Necesitamos un agente" | Un chat con botones | Un sistema con permisos sobre datos reales |
| "Entrénalo con nuestros datos" | Que el modelo aprenda de sus PDF | Semanas en el proyecto equivocado |
| "Que no alucine" | Un bug que se arregla | Un criterio de aceptación que no cierra nunca |
| "Con IA iremos mucho más rápido" | El mismo trabajo en menos tiempo | Fechas puestas sobre una cifra que nadie midió |
| "¿Esto ya está en producción?" | Si responde, está terminado | Tú eres el sistema de evaluación, en tu tiempo |
"Es solo un prompt" — por qué la estimación se te va al triple
Cree que el trabajo es redactar bien una instrucción. Medio día, uno si hay que probar variantes.
El prompt es la pieza pequeña. Alrededor va el contexto que le pasas, las herramientas que puede llamar, qué ocurre cuando devuelve basura y cómo compruebas que la semana que viene sigue funcionando igual. Todo eso junto es lo que conté en por qué un LLM por sí solo no es un producto.
El coste llega en la estimación: dijiste dos días pensando en la instrucción, y el ticket incluía en silencio todo lo demás. Cuando pides más tiempo, la conversación ya no es "el problema era más grande", es "¿por qué tardas el triple en escribir una frase?".
"Necesitamos un agente" — qué te están pidiendo en realidad
Cree que es un chat con botones que contesta en lenguaje natural.
De verdad es un bucle que decide por su cuenta, llama herramientas y tiene permisos sobre sistemas reales. La distancia entre las dos cosas la desarrollé en IA generativa vs IA agéntica, y es la distancia entre dos presupuestos.
El coste es que diste una estimación para un envoltorio de chat y te han pedido un sistema que actúa solo. Y "actúa" arrastra preguntas que no estaban en el ticket: sobre qué puede escribir, quién lo autoriza, cómo se detiene a mitad de ejecución, qué queda auditado.
Ninguna cabe en el sprint que ya tenía fecha antes de que existieran.
"Entrénalo con nuestros datos" — semanas en el proyecto equivocado
Cree que toca fine-tuning: echarle los PDF de la empresa al modelo y que aprenda.
Casi siempre lo que quiere es que el sistema busque en sus documentos antes de responder. Cuál toca en cada caso lo conté en RAG vs fine-tuning vs contexto.
El coste son semanas en el proyecto equivocado. Y lo peor no es el tiempo: después nadie lo lee como un malentendido de alcance, se lee como que "la IA no funcionó" y que el que la montó fuiste tú.
La versión hermana es "ponle memoria", que para quien lo dice significa acordarse de todo para siempre. Debajo hay ventana de contexto y coste por token. Si no sale antes, eliges arquitectura para sostener una expectativa que nadie revisó.
"Que no alucine" — el criterio de aceptación que no cierra nunca
Cree que es un bug: se abre ticket, se arregla, se cierra.
Es consecuencia de cómo funciona el modelo. Se acota con límites de dominio, verificación y citas, y se reduce mucho. No se elimina. El porqué está en por qué la IA se inventa cosas.
Este es el más caro de la lista por una razón concreta: se escribe. "El sistema no debe dar información incorrecta" aterriza tal cual como criterio de aceptación, y es una casilla que no vas a marcar nunca. No porque sea difícil: porque no se puede demostrar sobre entradas que no controlas. En la demo funciona y en la retro siguiente alguien trae un caso.
Te quedas como responsable indefinido de algo que, por diseño, no tiene línea de meta.
"Con IA iremos mucho más rápido" — la cifra que nadie midió
Cree que es el mismo trabajo en menos tiempo.
La IA mueve el cuello de botella: escribir código deja de ser lo caro, y especificar y revisar código que no escribiste pasan a serlo. Es lo que más ha cambiado en 15 años programando, y revisar es trabajo aunque no aparezca en ningún tablero.
El coste son fechas puestas sobre una cifra que nadie midió. Nadie dice en voz alta "asumamos que iremos un 40% más rápido": se asume en silencio y aparece en el roadmap.
Y cuando alguien lo mide en serio, el resultado incomoda. En el ensayo controlado de METR, 16 developers open-source experimentados resolvieron 246 tareas con y sin IA: creyeron que habían ido un 20 % más rápidos y en realidad tardaron un 19 % más. Cuidado con usar ese dato como arma, porque el propio METR lo da hoy por histórico —las herramientas eran de principios de 2025— y sirve justo para lo contrario de lo que parece: si los únicos que lo midieron con rigor ya no dan su número por vigente, nadie debería estar poniendo fechas sobre uno inventado.
Sin medición no hay defensa: si el trimestre se cumple, la IA funcionó; si no, el equipo no la supo aprovechar. Lo único que rompe el bucle es llegar con números propios, y de eso va cómo medir la productividad en equipos que usan IA.
"¿Esto ya está en producción?" — sin evals, el sistema de evaluación eres tú
Cree que si responde bien en la demo, está terminado.
Sin evals automáticos, que son los unit tests de un sistema con LLM, ni observabilidad, no sabes si funciona. Sabes que no ha explotado delante de ti todavía.
El coste es el más silencioso de todos: tú eres el sistema de evaluación. Cada ajuste de prompt, cada versión nueva del modelo, cada caso raro que reporta un cliente pasa por tu criterio, a mano. Ese trabajo no está en ninguna planificación y crece con el uso: cuanto mejor le va al producto, más de tu tiempo se come mantenerlo respirando.
Cómo explicar IA a tu jefe sin quedar de listo
Tener razón no sirve de nada si la forma de decirlo te deja fuera de la conversación. Quien pide esto tiene su propia fecha encima. Cuatro cosas que funcionan.
-
Traduce a decisión, no a definición. No expliques qué es un agente. Pregunta: "cuando dices agente, ¿quieres que actúe solo o que responda cuando le preguntan?". La definición no cambia nada; esa respuesta cambia el proyecto. Y la contesta él, así que la decisión sigue siendo suya.
-
Pon el tradeoff con números, aunque sean aproximados. "Dos semanas si solo responde, seis si actúa solo" convierte un debate de palabras en una elección con precio. Da siempre rango y nunca una fecha suelta: la fecha se te queda pegada. Y si puedes, remata con la versión pequeña: "el día 12 tienes la que responde y cita fuentes; la que actúa sola es otra conversación". No estás negociando el alcance desde arriba, estás poniendo algo antes sobre la mesa. Con eso discute muchísima menos gente.
-
Deja la decisión escrita. No hace falta un documento formal: dos líneas en el ticket o un correo con copia a los que estaban en la reunión. No es para tener razón después, sino para que el malentendido salga antes de escribir código. Si ahí pone "el sistema responde consultas, no ejecuta acciones sobre datos de cliente", quien lo lee contesta "espera, yo quería que ejecutara". Y te lo dice el martes, no en la demo del mes que viene. Ese es el argumento real para trabajar con especificaciones y la base del libro de Spec-Driven Development.
-
No pelees la palabra, pelea el alcance. Da igual cómo lo llame. Lo que tiene que quedar fijado por escrito es qué hace, con qué permisos y qué pasa cuando falla. Esas tres cosas son el contrato; el término es decoración.
Y si te toca opinar antes de que se apruebe el proyecto, ahí van cinco preguntas antes de aprobar un proyecto de IA.
Explicar IA a negocio es parte de tu trabajo técnico
Lo que cambió con la IA es el margen entre lo que negocio cree que pide y lo que hay que construir. Ese margen lo pagas tú en horas.
Mañana, en la próxima reunión donde suelten una de estas seis frases, no la corrijas. Haz una pregunta que fuerce una decisión y escribe la respuesta en el ticket con las palabras de quien la dijo.
Con eso dejas de heredar el malentendido. Y en un proyecto de IA, eso es la mitad del trabajo.
Estas conversaciones, sobre proyectos reales, pasan cada semana en Dominicode Labs.
Preguntas frecuentes
¿Cómo explico un proyecto de IA a mi jefe?
No lo expliques: conviértelo en una decisión suya. Pregunta si el sistema tiene que actuar por su cuenta o solo responder cuando le preguntan, pon precio a cada opción en la misma frase ("dos semanas si solo responde, seis si actúa solo") y escribe la respuesta en el ticket con sus palabras. La definición no cambia nada; esa decisión cambia el proyecto entero.
¿No es el trabajo de mi jefe entender lo que pide?
Entenderlo es su trabajo, sí, pero el coste de que no lo entienda cae en tu calendario, no en el suyo. Traducir hacia arriba no es un favor: es proteger tu propia estimación, y es una habilidad senior tan real como diseñar el sistema.
¿Cómo explico que "que no alucine" no es un requisito válido sin sonar a excusa?
No discutas el requisito: propón otro que sí se pueda verificar. Cambia "no debe dar información incorrecta" por "toda respuesta cita el fragmento del que sale, y si la búsqueda no devuelve nada, el sistema responde que no lo sabe".
Que eso último lo decida la búsqueda y no el modelo es lo que lo hace comprobable. Y añade la segunda mitad antes de que te la traigan ellos: sobre una lista fija de preguntas, alguien revisa que el fragmento citado sostenga la respuesta. Citar el documento correcto y tergiversarlo también es fallar.
¿Qué pregunto exactamente cuando alguien dice "necesitamos un agente"?
Pregunta una sola cosa: "¿quieres que actúe por su cuenta o que responda cuando le preguntan?". Si contesta que actúe, encadena tres más: sobre qué sistemas puede escribir, quién lo autoriza y qué pasa cuando se equivoca. Esas cuatro respuestas son el alcance real.
¿Cómo sé si me están pidiendo fine-tuning o búsqueda sobre documentos?
Pregunta qué pasa cuando el documento cambia. Si la respuesta es "tiene que responder con la versión nueva ya", están describiendo búsqueda sobre documentos, no entrenamiento. El fine-tuning ajusta cómo responde el modelo; si metes ahí información que cambia cada semana, te toca reentrenar cada semana.
¿Cómo estimo si negocio aún no ha decidido si el sistema actúa o solo responde?
No estimes el proyecto: estima las dos versiones. Un rango para la que solo responde y otro para la que actúa sobre datos reales, con la diferencia en una línea. Así la fecha queda atada a esa decisión y no a tu velocidad.
¿Y si mi jefe se molesta cuando le matizo un término?
No corrijas la palabra y ese roce casi nunca aparece. Lleva la conversación a qué hace el sistema, con qué permisos y qué ocurre cuando falla, y deja que él lo llame como quiera.
Y si ya se ha molestado, no lo resuelvas en la reunión. Escríbele después el comportamiento que entendiste, con sus palabras, y pregúntale si es eso. Cuesta mucho ofenderse con alguien que te está confirmando lo que pediste.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
