Esta es la reunión que está ocurriendo ahora mismo en unos cuantos miles de empresas.
Un miembro del consejo reenvía un artículo. ChatGPT y Gemini han superado los mil millones de usuarios cada uno. El correo dice cuatro palabras: "¿Cómo vamos con esto?". El CEO le pide al CTO un plan para el viernes. El CTO ya sabe algo que el consejo ignora: el lanzamiento del mes pasado necesitó una marcha atrás, el entorno de pruebas no coincide con producción desde marzo, y las dos personas que entienden el servicio de facturación están de vacaciones en agosto.
Así que el CTO hace lo racional en términos políticos. Promete un asistente de chat en el producto para el cuarto trimestre.
Esa decisión le costará a la empresa dos veces. Una para construir la función de IA. Otra para reconstruir la base que hay debajo, cuando esa función exponga todas las debilidades que el equipo ha estado sorteando en silencio durante tres años.
La adopción masiva no solo aumentó la urgencia. Subió el estándar.
La cifra de mil millones de usuarios suele leerse como una fecha límite. Es más útil leerla como un punto de referencia.
Antes, si tu herramienta interna tardaba seis segundos en devolver un resultado de búsqueda, los usuarios la comparaban con tu herramienta anterior. Ahora la comparan con algo que usaron en su móvil hace veinte minutos. Aquello empezaba a responder en menos de un segundo. Iba mostrando el texto mientras pensaba. Toleraba una errata, una frase a medio escribir y la foto de un recibo sin quejarse. Cuando no sabía algo, lo decía y ofrecía una alternativa cercana.
Mil millones de personas han sido entrenadas en cómo se siente lo bueno. No van a calificar tu función de IA con indulgencia solo porque sea la primera.
Esta es la parte que los consejos no ven. El titular presiona para lanzar algo. Pero ese mismo titular es lo que hace que lanzar algo mediocre sea peor que no lanzar nada. Una función de IA lenta, equivocada y olvidadiza no se lee como "primera versión". Se lee como "esta empresa no sabe hacer software". Gastas presupuesto y pierdes confianza en el mismo trimestre.
Las cuatro cosas que hace un buen asistente y que la mayoría de los sistemas corporativos no puede
Quita el modelo de la ecuación y mira qué le exige de verdad un asistente moderno al sistema que tiene detrás. Cuatro requisitos, y la mayoría de las plataformas heredadas falla en al menos tres.
Uno: un presupuesto de menos de dos segundos, de punta a punta. No para la llamada al modelo. Para todo.
User presses Enter
├─ 40ms TLS + edge routing
├─ 120ms auth check (JWT verify, cached)
├─ 250ms fetch user context (permissions, tenant, entitlements)
├─ 550ms retrieval: embed query → vector search → rerank
├─ 150ms prompt assembly + token accounting
├─ 700ms time to first token from the model
└─ then stream to completion
El modelo es la única línea que no puedes optimizar mucho. Todo lo que está encima es tuyo. Si tu comprobación de autenticación va a la base de datos en vivo porque nadie añadió una caché, ahí se van 400 ms. Si "obtener el contexto del usuario" significa cuatro llamadas HTTP internas en serie, ahí va otro segundo. Y si tu búsqueda es un LIKE '%query%' sobre una tabla de cuarenta millones de filas sin índice de cobertura, ya perdiste antes de preguntarle nada al modelo.
Los equipos descubren esto en la tercera semana del proyecto e intentan arreglarlo con una instancia más grande. No funciona. La latencia secuencial es un problema de arquitectura.
Dos: streaming. La velocidad percibida de todos los asistentes que la gente adora viene de que los tokens aparecen de inmediato. El código de aplicación para lograrlo es trivial:
export async function POST(req: Request) { const { messages } = await req.json(); const completion = await client.chat.completions.create({ model: "gpt-4o-mini", messages, stream: true, }); return new Response(toEventStream(completion), { headers: { "Content-Type": "text/event-stream", "Cache-Control": "no-cache, no-transform", "Connection": "keep-alive", "X-Accel-Buffering": "no", // nginx buffers your stream otherwise }, }); }
El código es la parte fácil. La difícil es que tu infraestructura se construyó para acumular respuestas completas antes de enviarlas. Bloqueos habituales: una capa nginx o un ALB que retiene el cuerpo hasta terminarlo, una pasarela de API con un tiempo límite fijo de 29 segundos, un firewall de aplicación que inspecciona todo el contenido antes de reenviarlo, un entorno serverless con tope de tamaño de respuesta, una CDN que descarta text/event-stream. Cada uno de esos puntos es un cambio de configuración que pertenece a alguien fuera de tu equipo de producto.
Por eso "añadir un cuadro de chat" se convierte en una negociación de seis semanas con infraestructura. Nadie puso eso en el plan del cuarto trimestre.
Tres: escribe datos, y lo hace de forma segura. Un widget de chat que solo lee datos es una demo. La IA útil actúa: cancela el pedido, reprograma la entrega, actualiza el registro. Eso significa que la salida del modelo llega ahora a tu ruta de escritura.
Las llamadas al modelo fallan. Las redes se cortan a mitad del flujo. Los usuarios pulsan dos veces. Así que los reintentos están garantizados, y reintentar sobre una ruta de escritura no idempotente significa registros duplicados y cobros dobles.
// Every AI-triggered write needs a key the model does not control. async function executeAction(action: Action, ctx: RequestContext) { const key = `${ctx.conversationId}:${ctx.turnIndex}:${action.name}`; return db.transaction(async (tx) => { const existing = await tx.actionLog.findUnique({ where: { key } }); if (existing) return existing.result; // replay, don't re-execute assertPermitted(action, ctx.actor); // authorise against the user, not the model const result = await handlers[action.name](action.args, tx); await tx.actionLog.create({ key, actor: ctx.actor.id, action, result }); return result; }); }
Si tu sistema no puede producir ese registro, no puedes responder a la única pregunta que importa después de un incidente: qué hizo la IA, sobre los datos de quién y con qué autorización. Ya escribimos sobre por qué la gobernanza tiene que ser código y no un documento de políticas. Esto es la versión concreta de ese argumento.
Cuatro: cambia de comportamiento sin un despliegue. Tu aplicación es determinista. La misma entrada, la misma salida, y una batería de pruebas que lo fija. Un modelo no. El proveedor publica una versión nueva, tu prompt se desvía, alguien añade una línea al mensaje del sistema, y la salida cambia.
Así que la capa de IA necesita otro tipo de prueba. No "¿la función devuelve 4?", sino "¿el sistema sigue dando la respuesta correcta en 200 casos conocidos?".
// evals/order-intent.test.ts const golden = loadCases("./cases/order-intent.jsonl"); // 200 real, anonymised inputs test("intent extraction holds above threshold", async () => { const results = await Promise.all(golden.map(runPipeline)); const exact = results.filter((r, i) => deepEqual(r.parsed, golden[i].expected)); const accuracy = exact.length / results.length; // Fail the build on regression, not on imperfection. expect(accuracy).toBeGreaterThan(0.93); });
Aquí importan dos cosas. Necesitas un umbral, no la perfección. Y necesitas entradas reales, lo que implica tener registros limpios de lo que los usuarios escribieron de verdad. Los equipos sin un registro de producción utilizable no pueden construir ese conjunto de casos. Suele ser la primera señal de que los cimientos no están listos.
La parte incómoda: el chat es la peor primera función de IA
El consejo habitual dice que empieces con un asistente de chat, porque es lo que todo el mundo reconoce. Ese consejo está al revés.
El chat es la interfaz más difícil que existe en software. Acepta entradas sin límite, así que no puedes acotar el problema. Da a entender que hay memoria, así que heredas la gestión de estado. Invita al usuario a preguntar cualquier cosa, así que cada hueco en tus datos se convierte en un fallo visible. Y mil millones de personas tienen una referencia de cómo debería sentirse, así que el estándar de calidad lo fija una empresa con un laboratorio de investigación.
Las mejores primeras funciones de IA son estrechas y aburridas. Un botón, una tarea, un resultado medible. Redacta esta respuesta. Clasifica este ticket. Extrae los campos de este PDF. Empareja este candidato con estos puestos. Controlas la entrada, puedes evaluar la salida y puedes poner una cifra al ahorro.
Las funciones estrechas también te permiten atacar los cimientos con honestidad. Hacer que una sola tubería de documentos sea rápida, observable e idempotente te obliga a arreglar cachés, colas y registros. Esos arreglos rinden en toda la plataforma. El chat, en cambio, extiende una capa fina de IA sobre todo y no arregla nada.
Hay una segunda razón para ir en estrecho. Las funciones amplias de IA necesitan contexto amplio, y los sistemas corporativos están demasiado enredados para entregárselos a un modelo en bloque. El problema de la ventana de contexto es un límite duro, no algo temporal. Un alcance estrecho es la forma de mantenerte dentro de él.
La prueba honesta
Antes de comprometerte con una fecha, responde a esto. No como lista de deseos, sino como diagnóstico de lo que existe hoy, en producción.
¿Puedes decir la latencia p95 de tus tres endpoints más usados sin abrir un panel en el que nadie confía? ¿Puedes lanzar un cambio un miércoles por la tarde sin un plan de marcha atrás que implique llamar a media empresa? ¿Tienes tres meses de registros limpios y consultables de entradas reales de usuarios? ¿Tu ruta de escritura sobrevive a una petición duplicada? ¿Puede un desarrollador montar un entorno realista en local en menos de una hora? ¿Hay alguien responsable del modelo de datos, o lo ha ido moldeando quien necesitaba una columna nueva más recientemente?
Seis "sí" honestos y estás listo para construir. Deberías moverte ahora, porque la ventana en la que una función de IA diferencia, en lugar de ser lo mínimo esperado, se está cerrando.
Tres o menos, y el proyecto de IA no es un proyecto de IA. Es un proyecto de estabilización con mejor traje. Ejecútalo como tal, a propósito, con la función de IA como objetivo declarado y los arreglos como el camino visible hacia ella. Ese encuadre es lo que consigue financiación para el trabajo de estabilización: los consejos aprueban presupuestos de IA, no de refactorización.
Qué significa esto para el próximo trimestre
El titular de los mil millones de usuarios es presión real, y no está equivocado. Tus clientes, tu personal y tu consejo dan por supuesta la competencia en IA igual que daban por supuesta una app móvil en 2012. Posponer es una decisión, y cada vez sale más cara.
Pero la urgencia y la preparación son preguntas distintas, y confundirlas es la razón por la que las empresas pagan dos veces. La respuesta correcta al titular no es un widget de chat para el cuarto trimestre. Son dos semanas de diagnóstico honesto y, después, uno de dos planes: arreglar la base o lanzar la función.
Nosotros hacemos ese diagnóstico por una tarifa fija, en dos semanas, y recibes un informe en rojo, ámbar y verde que puedes entregar a tu consejo. A veces la respuesta es "tus cimientos están mejor de lo que crees, adelante". A veces es "arregla estas cuatro cosas primero, y este es el orden". En cualquier caso dejas de adivinar, y eso vale más que otro trimestre prometiendo planes para el viernes.
Estabilizar primero. Mejorar después. Añadir IA al final. El orden no es prudencia. Es la única secuencia en la que la IA sigue funcionando seis meses después del lanzamiento.
Reserva una Auditoría Gratuita
