LLM en la empresa: por dónde empezar

Los modelos de lenguaje llegaron a las oficinas, muchas veces, antes que a los planes de IT: hay quien los usa para redactar un correo y quien los usa para resumir un contrato. En Italia, según el Istat, el instituto nacional de estadística (encuesta “Imprese e ICT”, diciembre de 2025), las empresas con al menos 10 empleados que usan al menos una tecnología de inteligencia artificial pasaron del 8,2% en 2024 al 16,4% en 2025, y el obstáculo más citado es la falta de competencias.

Para quien decide, la pregunta ya no es “¿funciona?”, sino “¿por dónde empiezo, sin malgastar presupuesto y sin poner en riesgo los datos?”. Aquí ordenamos lo que conviene tener claro antes de arrancar.

Qué es un LLM, en palabras sencillas

Un LLM (large language model, es decir, modelo de lenguaje de gran tamaño) es un programa entrenado con enormes cantidades de texto para predecir, fragmento a fragmento, la continuación más plausible de lo que recibe. De ese mecanismo nacen capacidades muy útiles: responder, resumir, traducir, extraer información, escribir código. Los nombres más conocidos son los modelos de OpenAI, Claude de Anthropic, Gemini de Google y, entre los que se pueden ejecutar por cuenta propia, Llama de Meta.

Dos aclaraciones. Un LLM no “sabe” las cosas como una base de datos: genera texto plausible, normalmente correcto pero no siempre. Y no conoce los documentos de tu empresa, salvo que se los proporciones tú en la propia petición.

Dónde aporta de verdad en la empresa

Los casos de uso que mejor funcionan tienen tres cosas en común: mucho texto, reglas bastante claras y una persona que revisa el resultado.

• Atención al cliente y asistentes internos: borradores de respuesta para el soporte, un asistente que resuelve dudas de los compañeros sobre procedimientos y normas internas.
• Redacción y resúmenes: actas, ofertas, resúmenes de contratos o de largas cadenas de correos, siempre como borrador para revisar.
• Extracción de datos: leer facturas, pedidos, currículos o formularios y pasar sus campos a un formato estructurado, listo para el ERP.
• Búsqueda en el conocimiento de la empresa: preguntas en lenguaje natural sobre manuales, wikis y archivos, con la respuesta y sus fuentes. Es el terreno de la técnica RAG (retrieval-augmented generation), a la que dedicamos un artículo aparte.
• Apoyo al desarrollo de software: autocompletado de código, tests, documentación, siempre con la revisión de un desarrollador y tests automáticos.

Empezar en pequeño: un proceso, una medida, un piloto

El error más habitual es partir de un objetivo genérico como “llevar la IA a la empresa”. Funciona mejor el camino inverso:

1. Elige un proceso: frecuente, repetitivo, con mucho texto y un coste que ya conoces (tiempo por expediente, tiempos de respuesta, errores).
2. Mide el punto de partida: sin un “antes” no hay un “después”. Bastan dos o tres indicadores.
3. Haz un piloto: pocas personas, datos reales pero controlados, una duración definida. Apunta también los casos en los que el modelo se equivoca.
4. Decide y luego amplía: si los indicadores mejoran, lo integras con los sistemas existentes (accesos, logs, monitorización) y lo extiendes a otros departamentos; si no, has gastado poco para descubrirlo.

Cómo se forman los costes

• Servicios en la nube por consumo: se paga por tokens, los fragmentos de texto (palabras o trozos de palabra) que el modelo lee y escribe, con precios distintos según el modelo y a menudo entre entrada y salida. Sin inversión inicial, pero con un gasto que crece con el uso.
• Modelos en servidores propios: se paga el hardware (normalmente servidores con GPU, los procesadores que aceleran estos cálculos), la energía y a quien lo gestiona. Coste más previsible, pero hacen falta una inversión inicial y competencias operativas.

No damos cifras porque las tarifas cambian a menudo: la estimación correcta es la que se hace con los volúmenes medidos en el piloto, con un tope de gasto desde el primer día. La comparación entre los dos caminos es el tema de nuestro artículo sobre modelos en casa o en la nube.

Privacidad y RGPD: adónde van los datos

Cada texto que se envía a un modelo en la nube sale de tu perímetro y hay que gobernarlo como con cualquier proveedor que trata datos por cuenta de la empresa.

• Qué datos: clasifica lo que entra en el modelo. Los datos personales, sanitarios o los secretos industriales exigen más cautela, desde la seudonimización hasta la prohibición de enviarlos.
• El contrato: hace falta un acuerdo de encargo del tratamiento (DPA, artículo 28 del RGPD) y hay que leer las condiciones sobre el entrenamiento. Anthropic, por ejemplo, declara que no entrena sus modelos con los datos de sus productos comerciales, API incluida; Google dice lo mismo de la API de Gemini de pago, pero no de la gratuita.
• La conservación: comprueba cuánto tiempo se quedan peticiones y respuestas en los servidores del proveedor y si existen opciones de conservación cero.
• El lugar: elige regiones europeas cuando puedas. Desde febrero de 2025 OpenAI ofrece a los clientes de API que cumplen los requisitos la residencia de datos en Europa; Claude en Amazon Bedrock y Gemini en Google Cloud Vertex AI se pueden usar con procesamiento dentro de la UE. Para los datos más delicados queda el modelo instalado en casa (on-premise).

En cuanto al AI Act europeo, desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia (como avisar a las personas cuando hablan con una IA), mientras que el Digital Omnibus, en vigor desde el 27 de julio de 2026, aplaza a 2027 y 2028 las normas sobre sistemas de alto riesgo. El marco sigue en movimiento: conviene revisarlo en cada proyecto.

Los riesgos: alucinaciones y revisión humana

El riesgo principal se llama alucinación: el modelo produce una información falsa con el mismo tono seguro que una verdadera. Se puede reducir, no eliminar. Las medidas que recomendamos:

• hacer que el modelo trabaje sobre tus documentos, no sobre su memoria, y pedir siempre las fuentes;
• mantener a una persona en el circuito para todo lo que llega a los clientes o tiene efectos reales (pagos, contratos, decisiones sobre personas);
• preparar preguntas reales con sus respuestas esperadas y repetir la prueba cada vez que cambian el modelo o las instrucciones;
• tratar con cautela los textos externos (correos, páginas web, adjuntos), que pueden esconder instrucciones pensadas para manipular el modelo (prompt injection).

Si estás valorando por dónde empezar, podemos ayudarte a elegir el primer proceso, montar y medir el piloto e integrarlo en tus sistemas. Encontrarás lo que hacemos en la página de servicios; para hablarlo, escríbenos.