Cómo implementar un LLM en una empresa

La empresa compró licencias para todos y a los tres meses nadie confía en el sistema

He visto esta escena repetirse con variaciones mínimas en compañías de rubros distintos. Recursos Humanos aprueba el gasto, TI activa las cuentas, y en la primera semana la adopción se dispara: todo el mundo prueba el chat, pide resúmenes, genera textos para el correo del viernes. Para el segundo mes el uso ya bajó a la mitad, y para el tercero lo sigue usando el mismo veinte por ciento de siempre, casi todos para tareas que ya hacían bien sin ayuda. Nadie lo usa para lo que de verdad costaba tiempo (revisar contratos, responder tickets repetidos, cruzar información de varios sistemas) porque nadie definió si el modelo puede tocar esa información, quién revisa lo que responde antes de que llegue a un cliente, ni qué número debería moverse si el proyecto funciona.

El error no es técnico, y tampoco es el modelo. La empresa no tenía un problema de falta de IA, tenía un vacío de decisiones que ninguna licencia resuelve por sí sola. Compró una herramienta genérica y esperó que el uso individual, sin ningún proceso alrededor, produjera un resultado de negocio. Eso no pasa nunca, ni con el proveedor más caro del mercado. Un LLM sin alcance definido, sin datos conectados a un propósito concreto y sin nadie que revise su salida no es un proyecto de inteligencia artificial: es una licencia de software que se factura todos los meses y que la mayoría termina abandonando para lo que en verdad dolía.

Las 5 decisiones que en verdad definen un proyecto de LLM en una empresa

Detrás de cualquier implementación seria de un modelo de lenguaje hay cinco decisiones, y ninguna es “qué marca elegimos”. Se resuelven en un orden específico, y ese orden importa tanto como el contenido de cada una:

Las primeras cuatro son las que fija esa definición. La quinta cierra la lista a propósito, porque debería decidirse al final y casi ninguna empresa lo hace así:

• Qué información entra: qué bases, documentos, historiales o sistemas puede consultar el modelo, y qué queda fuera de su alcance por defecto.
• Qué puede responder el sistema: sobre qué preguntas o procesos tiene permiso de contestar, y en qué casos debe callar y derivar a una persona.
• Quién revisa lo que sale: qué respuestas circulan sin supervisión y cuáles necesitan a alguien antes de llegar a un cliente o entrar en otro sistema.
• Contra qué número se mide: qué indicador debería moverse si el proyecto funcionó, y cuál era ese número antes de empezar.
• Qué modelo se usa: la elección de proveedor y versión, que solo tiene sentido una vez resueltas las cuatro anteriores.

Cuando una empresa arranca por el quinto punto (comparando modelos en una hoja de cálculo antes de resolver los otros cuatro) el proyecto avanza rápido en apariencia y se estanca en el primer mes real de uso. No porque el modelo elegido sea malo, sino porque nadie decidió lo que en verdad iba a determinar el resultado. Las empresas no siempre saben qué dolor tienen cuando piden “implementar IA”, y esas cinco preguntas son la forma de obligarlas a nombrarlo antes de firmar nada.

Por qué el modelo es la última decisión, no la primera

Cuando alguien me pregunta primero “¿qué modelo deberíamos usar?”, sé que todavía no tiene claro el proyecto. La pregunta se siente técnica y por eso da la sensación de avanzar, pero el modelo es la parte donde más se parecen las alternativas entre sí y donde menos pesa la diferencia entre ellas para el resultado final del negocio. He visto el mismo modelo funcionar de maravilla en una empresa y fallar en otra, con la única diferencia real de que la primera decidió bien qué información conectar y quién revisaba las respuestas, y la segunda conectó todo sin filtro y no le asignó esa revisión a nadie en particular.

El criterio para elegir el modelo, no la marca importa, pero es una decisión acotada: capacidad para la tarea, costo por uso, dónde vive el dato, soporte del proveedor. Se resuelve en días una vez que las otras cuatro decisiones ya están tomadas. Al revés, cuando el modelo se elige primero, la empresa termina moldeando el alcance del proyecto a lo que ese modelo hace bien, en lugar de elegir el modelo que sirve al alcance que el negocio necesita. Es la diferencia entre comprar una herramienta y después buscarle un uso, o partir del problema y elegir la herramienta que lo resuelve.

Qué necesitas tener de datos antes de conectar un LLM a algo real

La mayoría de proyectos de LLM en empresas no necesita entrenar el modelo desde cero ni ajustarlo con un proceso largo de entrenamiento propio. Necesita conectarlo, con criterio, a información que ya existe. Esa distinción cambia todo el presupuesto y el plazo del proyecto, y muy pocas propuestas comerciales la explican con claridad antes de cobrar. El valor no está en el modelo genérico ni en la conexión técnica: está en haber diagnosticado antes qué proceso del negocio se quiere mejorar y qué información sostiene ese proceso hoy.

• Documentación viva y centralizada: políticas, manuales y respuestas frecuentes que estén en un solo lugar, no repartidas en carpetas que nadie actualiza hace un año.
• Etiquetado de lo sensible: qué datos de clientes, contratos o finanzas no deberían entrar al contexto del modelo sin control, y quién lo decide.
• Permisos claros por rol: quién puede pedirle al sistema qué información, para que no termine respondiendo con datos que ese usuario no debería ver.
• Un dueño de la fuente: alguien responsable de que la información conectada se mantenga vigente, o el modelo empieza a responder con datos viejos con la misma seguridad de siempre.

Ese trabajo previo es exactamente lo que cubre cómo conectar un LLM con la información de la empresa (y con qué no conectarlo). Sin él, cualquier modelo, por bueno que sea, va a responder con la misma calidad que tiene la información a la que se lo conectó. Un sistema conectado a datos desordenados no arregla el desorden: lo repite con más velocidad y con apariencia de autoridad.

El circuito de revisión humana que casi ninguna empresa diseña a tiempo

La revisión humana no es una salvaguarda simbólica para tranquilizar a legal. Es la parte del proyecto que decide si un error del sistema se detiene a tiempo o llega a un cliente, a un contrato o a una decisión financiera. Y es, casi siempre, lo primero que se recorta cuando el proyecto tiene apuro por mostrar resultados.

• Umbral de confianza: a partir de qué nivel de certeza una respuesta sale sin pasar por una persona, y quién definió ese umbral.
• Punto de escalamiento: qué preguntas o temas van directo a un humano sin pasar por el modelo, sin excepción.
• Muestreo de auditoría: qué porcentaje de respuestas ya aprobadas se revisa después, para detectar errores que pasaron desapercibidos en el momento.
• Retroalimentación al sistema: qué se hace con el error detectado, para que el mismo error no se repita la semana siguiente.

La persona que ocupa ese rol de revisor no es un operador que aprueba por trámite: es quien conoce el proceso lo suficiente para notar cuándo el modelo suena seguro y está equivocado. Ese perfil, que combina criterio del negocio con manejo del sistema, es justamente lo que empieza a distinguir a un empleado AI Native de alguien que solo usa la herramienta. Sin ese circuito diseñado antes de lanzar, la empresa descubre el problema cuando ya salió mal, no antes.

Cómo se mide si el LLM está funcionando de verdad

El indicador equivocado, y el más común, es contar licencias activas o mensajes enviados. Eso mide uso, no resultado, y una empresa puede tener uso alto y valor de negocio nulo, que es exactamente el escenario del inicio de este artículo. La métrica correcta se ata a la decisión que motivó el proyecto, no al sistema en sí: si el objetivo era responder tickets más rápido, se mide tiempo de resolución antes y después. Si el objetivo era liberar horas de un equipo, se mide en qué se ocupan esas horas ahora.

• Una línea base previa: cómo se resolvía esa tarea antes del LLM, con el mismo nivel de detalle que se le va a pedir al sistema.
• Un indicador atado al proceso, no al uso: tiempo de resolución, tasa de errores detectados en revisión, porcentaje de casos resueltos sin escalar a una persona.
• Una ventana de medición realista: suficiente tiempo para que el equipo deje de estar en curva de aprendizaje y el número refleje uso estable.

Cómo evaluar un modelo de lenguaje en tu empresa entra en el detalle de cómo construir esa evaluación caso por caso. Lo que quiero dejar claro acá es más simple: si nadie puede decir con un número si el proyecto mejoró algo, no hay forma de defenderlo en la siguiente revisión de presupuesto, y tampoco de saber si conviene seguir invirtiendo en él.

El error de empezar por la licencia corporativa para todos

El instinto más común, y el más caro, es comprar acceso para toda la organización el primer día. Se siente como una señal de ambición (“la empresa entera va a usar IA”) y en la práctica es evitar la decisión difícil de elegir dónde apostar primero. El costo escala con la cantidad de empleados, no con el valor generado, y la mayoría de esas cuentas termina usándose para tareas menores que no necesitaban un proyecto de implementación, solo el hábito personal de cada usuario.

Una licencia por persona, sin un proceso definido detrás, es una automatización aislada disfrazada de estrategia, y las automatizaciones aisladas no son transformación. El camino que sí funciona empieza al revés: una sola área, un proceso con dolor real y medible, las cinco decisiones resueltas para ese caso puntual, un resultado que se puede mostrar con un número. Recién ahí se expande a otra área, con el aprendizaje del primer intento incorporado. Cuándo no usar inteligencia artificial en una empresa y cuánto cuesta usar un LLM en una empresa son las dos preguntas que casi nunca se hacen antes de firmar el contrato corporativo, y las dos que evitarían buena parte de estos proyectos fallidos. La IA no arregla una mala estrategia de despliegue: la expone más rápido y con una factura mensual de por medio.

Mi criterio sobre por dónde empezar

El costo real no está en el modelo, está en no haber decidido antes de encenderlo

La pregunta que de verdad separa un proyecto de LLM que sigue vivo a los seis meses de uno que se apaga solo no es qué modelo se usó. Es si alguien se sentó a decidir, antes de conectar nada, qué información entra, qué puede responder el sistema, quién revisa lo que sale y contra qué número se mide. Las empresas que saltan directo a la licencia están comprando la parte más barata y más rápida de todo el proyecto, y dejando sin resolver la que en realidad cuesta trabajo y en realidad importa.

Una organización que resuelve esas cuatro decisiones antes de elegir modelo se parece más a lo que entiendo por empresa AI Native que a una empresa con muchas licencias activas y poco que mostrar. La diferencia no se nota en el contrato que se firma. Se nota tres meses después, en si el sistema se sigue usando para el proceso que de verdad dolía, o si terminó como una aplicación más que nadie vuelve a abrir.