La brecha entre una buena demo y una función lista para producción
Todas las empresas con las que hablamos en 2026 ya han visto la demo. Alguien del equipo conectó un LLM a una hoja de cálculo, o construyó un chatbot sobre documentación interna en un fin de semana, y quedó genial en la reunión general. Después se quedó guardado en un canal de Slack durante tres meses, sin usarse en producción, porque nadie podía responder a la pregunta: ¿qué pasa cuando se equivoca delante de un cliente, o peor, delante de un auditor?
Esa brecha — entre "el modelo dio una buena respuesta una vez" y "esto funciona sin supervisión contra datos reales, para usuarios reales, todos los días" — es donde realmente se va casi todo el tiempo de nuestros proyectos de IA/ML. Escribir el prompt lleva una tarde. Hacer que sea seguro dejarlo funcionando es el proyecto.
Esto es lo que realmente separa una demo de un sistema en producción, y lo que cuesta cerrar esa brecha.
Las demos se saltan lo que hace que las cosas sean fiables
Una demo es una sola entrada, ejecutada una vez, por alguien que sabe cómo formular la pregunta. Producción son miles de entradas impredecibles, ejecutadas continuamente, por personas a las que no les importa ni les interesa cómo funciona el modelo. Tres cosas fallan primero cuando das ese salto:
1. No hay forma de saber si un cambio en el prompt mejoró o empeoró las cosas. Sin un conjunto fijo de casos de prueba y resultados esperados — un eval set — cada ajuste de prompt es una apuesta. Construimos un eval set a partir de preguntas reales de usuarios antes de tocar un prompt en producción, y lo volvemos a ejecutar con cada cambio de modelo o de prompt. Si un cliente no puede decirnos que la tasa de aciertos pasó de un número a uno mejor, no puede lanzar un cambio con seguridad — simplemente está confiando en la suerte.
2. El modelo es tan bueno como lo que es capaz de recuperar. Para cualquier cosa basada en tus propios datos — documentación de soporte, contratos, wikis internas — la calidad de la recuperación importa más que qué modelo estés usando. Un chunking ingenuo y una sola búsqueda vectorial te dan una demo que funciona con las tres preguntas que probaste. El RAG en producción necesita búsqueda híbrida (palabras clave más vectores), reranking, y la exigencia estricta de que cada respuesta cite su documento fuente. Si el sistema no puede señalar de dónde sacó una respuesta, no lo lances a nada de cara al cliente.
3. Los agentes que usan herramientas necesitan un modelo de permisos, no solo un prompt. En el momento en que un agente puede generar un reembolso, actualizar un registro en el CRM o enviar un correo en nombre de alguien, "el modelo decidió hacerlo" deja de ser una explicación aceptable. Cada acción necesita un radio de impacto definido: qué puede hacer el agente de forma autónoma, qué necesita un paso de aprobación humana y qué no puede tocar nunca. Mantenemos una lista explícita de acciones prohibidas para cada agente que construimos — normalmente cualquier cosa irreversible o financiera — antes de escribir la primera definición de herramienta.
El fallo que nadie prevé: respuestas incorrectas dichas con seguridad
Una caída de la API es evidente. Un modelo que responde con fluidez pero de forma incorrecta no lo es. Este es el riesgo concreto que más rápido destruye la confianza en una función de IA — una sola respuesta equivocada entregada con total seguridad, y el equipo que impulsó el proyecto se pasa el trimestre siguiente defendiéndolo.
La solución no es un modelo mejor. Es estructural: exigir citas en todo lo que se base en tus datos, añadir un umbral de confianza que derive las respuestas inciertas a una persona en lugar de adivinar, y registrar cada prompt, recuperación y respuesta para poder reconstruir exactamente qué pasó cuando algo sale mal. Tratamos esta capa de registro como innegociable, igual que trataríamos el registro de errores en un flujo de pagos. Nadie la nota hasta el día en que la necesita desesperadamente.
La automatización interna es el retorno de inversión en IA más rápido ahora mismo
Los agentes de cara al cliente se llevan la atención, pero el trabajo de IA con mayor certeza que hacemos en 2026 es interno: clasificar los tickets de soporte entrantes antes de que los vea una persona, resumir llamadas de ventas en notas del CRM, extraer partidas de facturas y contratos, y dejar que el personal haga preguntas sobre la documentación interna en lugar de escribir en un canal de Slack. Lo que está en juego es menor — una herramienta interna que a veces se equivoca la corrige un compañero, no un cliente — así que las barreras de seguridad pueden ser más ligeras y el retorno llega más rápido.
Un asistente RAG bien acotado sobre la documentación propia de una empresa es, en la práctica, un proyecto desde $7,000+ con un prototipo funcional en 2 a 4 semanas, y una versión endurecida para producción — autenticación, registro, un eval set, citas de fuentes — en 8 a 12 semanas. Los agentes que usan herramientas conectados a sistemas reales (un CRM, un sistema de tickets, un ERP) empiezan alrededor de $20,000+, porque el trabajo de permisos y pruebas escala con lo que se le permite tocar al agente. La automatización de flujos de trabajo pura — sin ningún modelo en el proceso, solo movimiento fiable de datos entre herramientas — empieza más bajo, desde $3,000 por una sola integración.
Lo que exigimos antes de escribir el primer prompt
En todo proyecto de IA, cuatro cosas se deciden antes de que se lance código, no después:
- Un responsable del eval set. Alguien cuyo trabajo sea notar cuándo baja la calidad, no "el equipo" en abstracto.
- Una lista documentada de acciones prohibidas. Las acciones concretas que el sistema nunca puede realizar sin que una persona lo confirme antes.
- Un techo de costo. Presupuestos de tokens por usuario o por día, con alertas antes de que la factura sorprenda a alguien. Clasificación con un modelo económico y escalado a un modelo de frontera, no un modelo de frontera para todo.
- Un plan de reversión. Los proveedores de modelos cambian el comportamiento bajo un mismo nombre de API estable con más frecuencia de lo que los equipos esperan. Si la precisión baja tras una actualización silenciosa del proveedor, necesitas una versión anterior del prompt y una puntuación de eval anterior con la que comparar.
Sáltate cualquiera de estos puntos y el proyecto no falla de forma ruidosa — falla en silencio, semanas después del lanzamiento, cuando alguien nota que el sistema lleva un tiempo equivocándose con seguridad y nadie estaba vigilando.
La conclusión
El modelo casi nunca es el cuello de botella en 2026. Las APIs de frontera de OpenAI y Anthropic, combinadas con frameworks de recuperación como LlamaIndex y bases de datos vectoriales como pgvector, son suficientemente buenas para la inmensa mayoría de los casos de uso empresariales. Lo que determina si una función de IA sobrevive al contacto con usuarios reales es la ingeniería poco vistosa que la rodea: evals, fundamentación en datos, permisos, registro y un modelo de costos que no sorprenda a finanzas.
Ese es el trabajo que hace nuestro equipo de IA y machine learning — convertir una demo que funciona en un sistema que una empresa realmente puede dejar funcionando sin supervisión. Si lo que más te interesa es el lado de la automatización interna — conectar herramientas y eliminar trabajo repetitivo en lugar de construir una nueva función de IA — nuestro equipo de automatización e integraciones aborda esos proyectos de la misma manera: prototipo rápido, y se endurece antes de que toque algo que importe.
