Por qué las empresas queman peticiones de IA tras preparar los datos y siguen sin un resultado fiable — y por qué la pieza que falta es una persona dueña del proceso y de las pruebas de aceptación.

Resumen

Pregunta	Respuesta corta
Preparamos bien los datos — ¿por qué el agente sigue sin ser fiable?	Porque la preparación arregla las entradas. Especificar el proceso — cada excepción, cada caso límite — es un trabajo aparte que la herramienta asume que alguien ya hizo
¿Entonces los modelos no son suficientemente buenos?	Son excelentes y siguen mejorando (Claude Opus 5, GPT-5.x). El cuello de botella se movió del modelo a la especificación
¿Para quién construye OpenAI estas herramientas?	Su lanzamiento de AgentKit lo dice claro: «desarrolladores y empresas» — gente que ya sabe especificar un sistema
¿Qué hace la persona que falta?	Arbitra contradicciones, decide casos límite, construye las pruebas de aceptación y es dueña del proceso de cambio
¿Cuándo basta con hacerlo uno mismo?	Productividad personal, documentos de un solo uso, prototipos desechables
¿Cómo se ve «terminado»?	Un sistema con roles, pista de auditoría, pruebas y marcador de impacto — mira la demo en vivo en demo.kamensky.dev

Esta es la segunda mitad de una historia. En la primera limpiamos los datos: una lista de precios canónica, estados controlados, proceso documentado, un conjunto de pruebas. Ese trabajo es real y da sus frutos. Y sin embargo, un número notable de equipos se atasca después durante meses en el mismo sitio: prompts, más prompts, pagando agentes que deslumbran en la demo y fallan el lunes.

El fallo no está en la preparación. Está en lo que ningún prompt puede suministrar.

Primero, el crédito que corresponde

Las herramientas mejoraron de verdad. El AgentKit de OpenAI trae un Agent Builder visual; los GPT personalizados se conectan a tu Drive; los proyectos y workspaces de Claude ingieren documentos y construyen apps funcionales; los modelos de frontera siguen subiendo — Claude Opus 5 llegó en julio de 2026 afinado explícitamente para agentes de larga duración. Para una persona técnica, la distancia de la idea al prototipo funcional se ha desplomado a horas.

Vuelve a leer el anuncio de AgentKit, eso sí, y fíjate en la audiencia: «un conjunto completo de herramientas para que desarrolladores y empresas construyan, desplieguen y optimicen agentes». Desarrolladores y empresas. La herramienta asume que alguien de tu lado puede especificar el sistema: cuál es el proceso, dónde viven las excepciones, qué significa «correcto», qué pasa cuando algo falla. Si nadie de tu lado puede — y en una pyme típica, nadie puede — la herramienta no elimina esa necesidad. Simplemente la deja sin cubrir.

Siete modos de fallo que más prompts no pueden arreglar

1. Alguien debe arbitrar las contradicciones. Tu director comercial dice que las devoluciones son de 14 días; tu jefe de operaciones dice 30; ambos tienen «razón» para distintos segmentos de clientes. Un agente con ambas reglas no escala el conflicto — elige una, invisiblemente. La competencia central de un analista de negocio es convertir «ambas, depende» en una regla escrita con excepciones nombradas. Esa decisión es trabajo de negocio, no de prompt.

2. Los casos límite son el sistema. El camino feliz es el 20% del proceso y el 100% de la demo. El valor está en la cola larga: el cliente con dos entidades legales, el pedido hecho a las 23:58 del 31 de diciembre, la entrega parcial, la revalorización de divisa a mitad de factura. No están en ningún archivo — viven en las cabezas de tus dos personas más experimentadas. Extraerlos son entrevistas, pizarras y decisiones. Las peticiones al modelo no los sacan a la luz; las preguntas a tu gente, sí.

3. Leer es fácil; escribir con seguridad es ingeniería. Los agentes de chat leen tus Sheets sin problema. Escribir de vuelta — sin crear filas duplicadas cuando dos personas editan a la vez, sin perder una actualización cuando la red cae a mitad de guardado, sin que el agente «servicialmente» sobrescriba un precio — requiere transacciones, bloqueos y gestión de conflictos. Ningún producto de chat hace esto porque no es un problema de chat; es un problema de plataforma de datos. (Es el mismo muro que Sheets choca al escalar, con otro sombrero.)

4. Sin un bucle de evaluación, no puedes distinguir «mejor» de «distinto». Ajustas el prompt; las respuestas cambian. ¿Son más correctas? Nadie lo sabe, porque no hay un conjunto de pruebas congelado ni nadie cuyo trabajo sea medir. El bucle se vuelve una cuestión de gusto: prompt, entrecerrar los ojos, prompt otra vez. Así ocurren los «cientos de peticiones» — no porque el modelo sea débil, sino porque nada define el éxito. El conjunto de pruebas de la fase de preparación es la mitad de la solución; la otra mitad es una persona que lo ejecute tras cada cambio y firme el resultado.

5. Un proceso de negocio debe funcionar igual cada vez. Los agentes son probabilísticos; tu mesa de pedidos no tiene permiso para serlo. «Normalmente aprueba el descuento correcto» no es un estándar operativo — es un informe de incidente esperando fecha. La fiabilidad viene de envolver al agente en raíles deterministas: validación, reintentos, idempotencia, una pista de auditoría de quién cambió qué. Construir esos raíles es ingeniería alrededor del agente, no conversación con él.

6. Alguien debe ser dueño del proceso de cambio. La lista de precios cambia el martes. Si los datos de referencia tienen dueño y regla de actualización, el agente vuelve a estar en lo correcto en minutos. Si no, sigue equivocándose con confianza hasta que un cliente lo nota. Todo sistema real necesita ese dueño — una persona responsable de mantener la verdad verdadera. Los proveedores te venden el agente; el dueño no viene en ningún plan.

7. La confianza se gana y luego se mantiene. Un equipo abandona un sistema tras aproximadamente dos malas respuestas, y hace bien. Reconstruir la confianza exige exactamente lo que aporta un analista: el incidente revisado, la regla corregida en un solo sitio, el test ampliado con ese caso, y la corrección demostrada — no otro prompt esperanzado.

La economía de iterar en prompts

Iterar prompts parece gratis porque cada petición es barata. No lo es: con los precios medidos de las herramientas de chat, un libro de 40 pestañas re-leído por sesión más el prompteo exploratorio escala con la actividad, no con los resultados — y el coste real son los meses que tu equipo de operaciones pasa a medias entre el proceso viejo y el agente. La alternativa no es un prompt mejor. Es una especificación: el documento de proceso, el registro de casos límite, el conjunto de pruebas y los criterios de aceptación de la checklist de preparación — producidos una vez, por una persona, en semanas — tras lo cual los agentes se vuelven baratos y fiables.

Por qué el rol que falta es un analista de negocio, ante todo

Observa que de los siete modos de fallo anteriores, solo el 3 y el 5 son sustancialmente ingeniería. Los otros cinco son análisis de negocio: arbitrar reglas, extraer conocimiento no escrito, definir corrección medible, ser dueño de los datos de referencia, ejecutar la aceptación. Por eso «contratar un prompt engineer» rescata tan rara vez estos proyectos — el cuello de botella nunca fueron los prompts.

Es también la descripción honesta de lo que hago. Pasé 17 años dentro de operaciones de negocio antes de construir software: carrera de economía, analítica industrial, análisis de negocio, automatización de SAP y Excel en empresas reales. Hoy dirijo esa disciplina de descubrimiento como paso uno de cada proyecto de automatización — y luego construyo los agentes y la plataforma a su alrededor, de modo que el resultado tiene roles, permisos, pista de auditoría, copias de seguridad y una batería de pruebas. El mismo proceso, aplicado a tus datos, es visible de punta a punta en demo.kamensky.dev: el pipeline de migración, la plataforma de operaciones autenticada que tu equipo usaría de verdad, y el marcador que muestra las horas y los dólares.

Si tu equipo está atascado en el bucle de prompts, el siguiente paso más barato no es otra petición. Reserva una llamada de encaje de 20 minutos — trae el proceso que duele; saldrás sabiendo si es un problema de datos, de especificación o de plataforma, y cuánto cuesta arreglar cada uno.

Cuándo basta con hacerlo uno mismo

La frontera honesta: productividad personal (resumir, redactar, traducir), preguntas analíticas puntuales sobre un único archivo limpio, y prototipos desechables que validan una idea antes de invertir. Para eso, las herramientas integradas son excelentes y este artículo no aplica. En cuanto un proceso corre semanalmente, toca dinero o clientes, o necesita que dos personas se pongan de acuerdo sobre los números — aparece el rol que falta, lo haya previsto alguien o no.

Fuentes y lecturas adicionales

• Introducing AgentKit — OpenAI — nótese la audiencia prevista
• Introducing Claude Opus 5 — Anthropic — los modelos siguen mejorando; el cuello de botella se movió
• How to Prepare Your Business Data for AI Agents — la primera mitad de esta historia
• Your Replit or Lovable App Isn’t Production-Ready — precios verificados de builders y la matemática de costes medidos
• Three AI Agents I Run in Production — el patrón de raíles deterministas en la práctica