El PLN ya no es 'sentimiento en tuits'. Seis casos por los que empezar - contratos, triaje de soporte, llamadas de ventas - y cómo medir cada uno.
Contenido7 secciones
Lo que cambió: el PLN ya no es difícil de desplegar
Antes de 2023: desplegar un sistema de PLN en los negocios exigía un equipo de ML, datos etiquetados de entrenamiento, infraestructura MLOps y meses de trabajo. El trabajo consistía en construir modelos específicos por tarea (BERT para clasificación, T5 para resumen, NER personalizado para extracción).
2026: la mayor parte del PLN en los negocios son llamadas de API a un LLM comercial, con ingeniería de prompts y salida estructurada, y el modelo sigue abaratándose: el precio del rendimiento de nivel GPT-3.5 cayó más de 280 veces entre noviembre de 2022 y octubre de 2024. El cuello de botella se movió del entrenamiento del modelo a la definición del alcance.
Resultado: casos de uso de PLN que no eran económicamente viables en 2022 merecen hoy un piloto.
Seis casos de uso por los que empezar
1. Revisión de contratos
El LLM compara el contrato recibido con el playbook. Señala desviaciones. Sugiere correcciones. Lo enruta al área legal para la firma.
- Qué medir: proporción de desviaciones marcadas con las que el abogado está de acuerdo y tiempo de revisión por contrato, sobre una muestra de tus contratos pasados
2. Triaje de tickets de soporte
El LLM clasifica el ticket entrante, redacta la primera respuesta desde la base de conocimiento y lo enruta al N1 o al N2.
- Evidencia: en un estudio de 5.179 agentes de soporte, un asistente de IA generativa aumentó los casos resueltos por hora un 14% de media y un 34% en los novatos
- Qué medir: proporción de borradores enviados sin cambios y tiempo hasta la primera respuesta
3. Resumen de llamadas de ventas
El LLM transcribe (API Whisper), extrae decisiones, próximos pasos, objeciones y acciones. Publica en el CRM y en Slack. La misma extracción puede hacerse durante la llamada, cuando quien habla es un agente de voz: llama a un agente de demostración desde el navegador y mira el registro que deja en el CRM.
- Qué medir: acciones que el vendedor tuvo que corregir y minutos de registro en el CRM ahorrados por llamada
4. Preguntas y respuestas sobre documentos / RAG
El usuario hace una pregunta; el LLM recupera los documentos relevantes del almacén vectorial y responde con citas. Se usa en bases de conocimiento internas, documentación de soporte al cliente y archivos de cumplimiento.
- Qué medir: proporción de respuestas cuya fuente citada realmente las respalda, sobre un conjunto fijo de preguntas reales
5. Categorización de correos
El LLM clasifica el correo entrante por intención (lead de ventas, soporte, facturación, etc.) y lo enruta a la bandeja/equipo correcto.
- Qué medir: correos mal enrutados por semana, contados por los equipos que los reciben
6. Criba de currículos
El LLM extrae datos estructurados de los currículos (habilidades, años de experiencia, formación) y puntúa la afinidad con los requisitos del puesto.
- Qué medir: coincidencia con las decisiones del reclutador en una muestra reservada, revisada por separado para cada grupo
- Nota: las pruebas de sesgo son obligatorias (EU AI Act, EEOC de EE. UU.) antes del despliegue
LLM comercial frente a código abierto
La matriz de decisión en 2026:
| Factor | Comercial (OpenAI, Anthropic, Google) | Código abierto (Llama, Mistral, Qwen) |
|---|---|---|
| Tiempo hasta el primer despliegue | Más rápido | Más lento (hay que montar servidores) |
| Calidad (tareas generales) | Mayor | Menor (en mejora) |
| Costo por llamada (escala pequeña) | Más barato | Más caro (costo de servidor) |
| Costo por llamada (gran volumen) | Más caro | Más barato |
| Residencia de datos | Compromisos | Control total |
| Flexibilidad de ajuste fino | Limitada (ofertas del proveedor) | Control total |
| Carga operativa | Ninguna | Significativa (servidores GPU) |
Por defecto: comercial. Pasa a código abierto cuando se alcancen los puntos de cruce. La mayoría del SaaS B2B en 2026 sigue usando APIs comerciales. Cuando pases a modelos propios, lee implementar modelos de ML en producción.
Por qué el RAG sigue importando con contextos de 1 millón de tokens
Desde febrero de 2024 hay modelos con ventanas de contexto de 1 millón de tokens disponibles para desarrolladores. Algunos equipos concluyeron que el RAG era obsoleto. No lo es.
Razón de costo. La entrada se cobra por token, así que una solicitud de 1 millón de tokens paga 200 veces la entrada de los 5.000 tokens relevantes. A escala, esa es la diferencia entre una funcionalidad rentable y una inasumible.
Razón de calidad. Los modelos responden mejor cuando el pasaje relevante está al principio o al final de un contexto largo y bastante peor cuando está en el medio - el problema 'lost in the middle'. Un fragmento relevante de 5.000 tokens pone la respuesta donde el modelo lee mejor.
Arquitectura RAG en 2026:
Consulta
-> Modelo de embeddings (texto -> vector)
-> Recuperación en almacén vectorial (top-K fragmentos)
-> Reranker (opcional, refina el top-K)
-> LLM con los fragmentos recuperados como contexto
-> Respuesta con citas
Herramientas: Pinecone, Weaviate, Qdrant para almacenes vectoriales. Cohere Rerank, Voyage AI para rerankers. El patrón está maduro; elige componentes, no una "plataforma RAG".
Evaluación de calidad a escala
Tres capas, todas obligatorias:
-
Métricas automatizadas donde haya verdad de referencia. F1 de clasificación, precisión de extracción, recall@K en recuperación. Ejecuta en cada despliegue.
-
LLM como juez para calidad subjetiva. Usa un modelo más fuerte para puntuar la salida del modelo de producción según una rúbrica (¿el resumen capta los puntos clave?, ¿el tono es apropiado?). Valida el juez LLM contra muestras humanas una vez al mes.
-
Revisión humana por muestreo del 5-10% de la salida en producción. De forma continua y aleatoria. Es la única manera de detectar lo que las dos primeras capas dejan pasar.
Saltarse cualquier capa crea un punto ciego de calidad. Hemos visto sistemas de PLN en producción degradarse en silencio durante meses porque nadie miraba la calidad de la salida. Para integrar este flujo en un programa más amplio, ver integración de IA en los negocios.
Un despliegue de PLN en 60 días
Semanas 1-2: elige el caso de uso. Define el formato de entrada, el formato de salida y la métrica de éxito (precisión de extracción, F1 de clasificación, calidad del resumen).
Semanas 3-4: construye el prompt o el pipeline. Pruébalo con 100 ejemplos. Itera los prompts. Mide la precisión.
Semanas 5-6: despliega en producción detrás de una feature flag. Encamina el 10% del tráfico. Monitorea precisión y costo a diario.
Semanas 7-8: escala al 100% del tráfico. Configura las tres capas de evaluación de calidad. Documenta el patrón.
Para el día 60, el equipo tiene un sistema de PLN en producción con precisión medida, calidad monitoreada y costo documentado. El siguiente parte del mismo patrón.
La conclusión
El PLN en los negocios en 2026 es, en gran medida, ingeniería de API, no ingeniería de ML. Seis casos de uso (revisión de contratos, triaje de soporte, extracción de llamadas de ventas, preguntas y respuestas sobre documentos, categorización de correos, criba de currículos) son buenos puntos de partida. La restricción es el alcance (un flujo, una métrica) y la evaluación de calidad (tres capas, todas obligatorias). Los LLM comerciales cubren la mayor parte de las necesidades de PLN en los negocios, y el precio de un mismo nivel de capacidad sigue bajando. Los modelos de código abierto importan a gran escala o bajo restricciones de residencia de datos. Elige un caso de uso, ponlo en producción en 60 días, instrumenta la calidad y pasa al siguiente. Para traducir las horas ahorradas a una cifra trimestral, ver medir el ROI de la IA.
Preguntas frecuentes
¿Qué cambió en PLN entre 2022 y 2026?
Antes de 2023: PLN significaba entrenar modelos específicos por tarea (BERT para clasificación, T5 para resumen, NER personalizado). Exigía equipo de ML, datos etiquetados, MLOps. 2023-2024: GPT-3.5 y GPT-4 hicieron posible saltarse el entrenamiento - das un prompt al modelo y obtienes el resultado. 2024-2025: el precio del rendimiento de nivel GPT-3.5 cayó más de 280 veces entre noviembre de 2022 y octubre de 2024 (Stanford AI Index 2025), las ventanas de contexto llegaron a 1 millón de tokens, la salida estructurada se volvió fiable. La barrera para hacer PLN en los negocios pasó de 'equipo de ML' a 'clave de API'.
¿Debemos usar LLM comerciales o modelos de código abierto?
Por defecto, APIs comerciales (OpenAI, Anthropic, Google) para prototipos y la mayor parte de la producción. Pasa a código abierto (Llama, Mistral, Qwen) cuando (a) el costo por llamada sea relevante a escala, (b) los requisitos de residencia de datos prohíban las APIs comerciales o (c) necesites ajuste fino más allá de lo que ofrecen los proveedores comerciales. Dónde está el punto de cruce en costo depende de tu volumen y del precio de las GPU, así que calcúlalo con tu propio número de llamadas.
¿Qué tan precisa es la extracción de documentos basada en LLM?
Depende de lo bien definido que esté el campo y de lo limpia que sea la fuente: un número de factura de una factura estructurada es mucho más fácil que las obligaciones clave de un contrato mal redactado. Mide la precisión por campo sobre una muestra etiquetada de tus propios documentos antes de salir a producción. Los errores que queden deben tolerarse, detectarse con validación o enviarse a revisión humana. Planifícalo en el diseño del flujo.
¿Seguimos necesitando RAG en 2026 con ventanas de contexto de 1 millón de tokens?
Sí, por dos razones: (1) costo - la entrada se cobra por token, así que una solicitud de 1 millón de tokens paga 200 veces la entrada de los 5.000 tokens relevantes; (2) calidad - los modelos responden mejor cuando el pasaje relevante está al principio o al final de un contexto largo y bastante peor cuando está en el medio (Liu et al., 2023, el problema 'lost in the middle'). RAG con recuperación sobre un almacén vectorial sigue siendo la arquitectura correcta para cualquier caso de uso intensivo en documentos.
¿Cómo evaluamos la calidad de salida del PLN a escala?
Tres capas: (1) métricas automatizadas donde haya verdad de referencia (precisión de extracción, F1 de clasificación); (2) LLM como juez para calidad subjetiva (¿el resumen capta los puntos clave?), validado con muestras humanas; (3) revisión humana por muestreo del 5-10% de la salida en producción, de forma continua. Saltarse cualquier capa crea un punto ciego de calidad.
