OpenAI en la empresa: para qué sí y para qué no

El error de empezar por OpenAI

Cuando una empresa me dice "queremos usar OpenAI", casi siempre está describiendo una herramienta, no un problema. La conversación arranca por el modelo, por la API, por el asistente que vieron en una demo. Ese es el orden equivocado. OpenAI es tecnología seria, de las mejores que hay hoy. Pero una pieza no es un sistema, y una herramienta no es una estrategia.

El patrón se repite: alguien monta un asistente interno, le conecta la documentación de la empresa, lo presenta en una reunión. Tres semanas después nadie lo abre. No falló el modelo. Falló la pregunta inicial. Nadie definió qué proceso dolía, quién era dueño del resultado ni qué número tenía que moverse. La IA no arregla ese vacío: lo hace más caro.

Para qué sí tiene sentido

Un modelo de OpenAI rinde en un tipo de trabajo muy concreto: lenguaje y juicio flexible. Donde el input es humano, desordenado y ambiguo, y una regla fija se rompe. Ahí sí paga la operación.

• Interpretar texto no estructurado: correos, tickets de soporte, contratos, transcripciones. Extraer lo que importa y clasificarlo.
• Redactar borradores que un humano revisa: propuestas, respuestas comerciales, resúmenes de reunión. El modelo acelera, la persona decide.
• Responder sobre el conocimiento interno de la empresa, conectando el modelo a datos propios y no a su memoria general.
• Tomar decisiones con criterio flexible donde una regla rígida deja demasiados casos afuera: priorizar leads, enrutar solicitudes, detectar intención.
• Convertir lenguaje en acción estructurada: leer un pedido en texto libre y devolver datos limpios que otro sistema ya pueda consumir.

Para qué no (o todavía no)

El mismo modelo es una mala elección cuando el trabajo exige exactitud, determinismo o costo mínimo por operación. Ahí una regla, una fórmula o un script clásico gana sin discusión.

• Cálculos exactos y contabilidad. Un modelo de lenguaje no es una calculadora ni un libro mayor. Para eso hay SQL y hojas de cálculo.
• Procesos de altísimo volumen y variación casi nula. Si un script hace lo mismo por centavos, pagar tokens es quemar plata.
• Salidas que deben ser reproducibles y auditables sin variación. Un modelo puede responder distinto ante la misma entrada, y en ciertos procesos eso es inaceptable.
• Cuando los datos no existen o están sucios. El modelo no inventa el orden que la empresa nunca hizo.
• Cuando nadie va a revisar la salida y el error tiene costo legal o financiero directo.

La sobreingeniería que nadie va a usar

El otro extremo cuesta tanto como no hacer nada: montar el sistema más complejo posible para un problema que pedía algo simple. Base de datos vectorial, varios agentes, fine-tuning, orquestación, todo junto, para una tarea que una sola llamada bien escrita resolvía.

La ingeniería de los propios proveedores insiste en lo mismo: empezar por lo más simple que funcione y subir en complejidad solo cuando el resultado lo justifique. En la empresa esto no es un consejo técnico, es una decisión de plata. Cada capa que agregas es costo de construcción, de mantenimiento y de gente que después tiene que entenderla.

Dónde encaja OpenAI en un proceso

La herramienta va al final, no al principio. El orden que uso no cambia porque el proveedor se llame OpenAI:

• 1. Dolor. Qué pierde la empresa hoy, medido en tiempo y en plata, no en tecnología.
• 2. Proceso. Cómo ocurre de verdad ese trabajo, con sus cuellos de botella reales, no como dice el manual.
• 3. Datos. Qué información hace falta, dónde vive y si está limpia.
• 4. Herramienta. Recién aquí se decide si la subtarea es de lenguaje o de juicio flexible. Si lo es, OpenAI entra. Si no, entra otra cosa.

OpenAI no compite con tu proceso. Ocupa un lugar dentro de él, y solo en los pasos donde un modelo de lenguaje hace algo que una regla no puede.

El criterio de decisión

Antes de escribir una línea de código o abrir una cuenta, cinco preguntas ordenan la decisión:

• ¿La tarea es de lenguaje o de juicio flexible, o es cálculo exacto? Si es exacto, no es trabajo para un modelo.
• ¿Una regla simple ya lo resuelve? Si sí, no pagues un modelo para lo que un "if" hace gratis.
• ¿Hay un humano revisando donde el error cuesta? Si el error es caro y nadie revisa, el modelo todavía no entra ahí.
• ¿Los datos existen y están accesibles? Sin datos propios, el modelo responde en general, no sobre tu negocio.
• ¿Hay un KPI con dueño? Si nadie puede nombrar el número que mejora, el proyecto muere en la siguiente revisión de presupuesto.

Cómo saber si sirvió

Usar OpenAI no es un resultado. El resultado es el número que se movió. Lo que mido cuando un modelo entra a un proceso:

• Tasa de aceptación: cuántas salidas del modelo el humano usa sin corregir.
• Tiempo por tarea, del antes al después.
• Costo por tarea completada, incluyendo tokens y operación.
• Errores que llegaron al cliente o al paso siguiente.
• Adopción real: cuánta gente lo usa un mes después, no en la demo.

Si ninguno de esos se mueve, el problema no es el modelo ni el proveedor. Es que se resolvió el dolor equivocado. Y eso se detecta en el diagnóstico, no en la factura.