Seis casos reales de integrar OpenAI, Gemini o Claude en una empresa, con el criterio de datos que aplico siempre: qué información sale a la nube, qué no, y cuándo conviene un modelo local.
Integrar la IA de OpenAI, Gemini o Claude en tu empresa consiste en conectar un modelo de lenguaje a un proceso concreto que hoy te consume horas, decidiendo antes qué datos pueden salir a la nube y cuáles deben quedarse dentro del edificio. No se trata de "poner un chatbot" porque quede moderno, sino de elegir una tarea repetitiva, medible y con reglas claras, y automatizarla con un modelo que se integra en tus sistemas actuales. En este artículo repaso seis casos de uso reales, con el criterio que aplico siempre: qué información viaja fuera, qué no, y cuándo conviene un modelo local para que nada abandone tu infraestructura.
Trabajo como desarrollador full-stack senior en Aspe, Alicante, y llevo más de veinte años escribiendo código. Cuando una PYME o una agencia me pide "meter IA", lo primero que hago no es abrir una API: es mirar el flujo de trabajo y ver dónde el modelo aporta un resultado, no una demo. Esa es la diferencia entre gastar dinero y automatizar de verdad.
Antes de decidir entre OpenAI, Gemini, Claude o un modelo local, decido qué categoría tiene el dato que va a procesar el modelo. Esto no es un detalle técnico menor: es lo que marca la arquitectura entera del proyecto y también la factura mensual.
Distingo tres niveles:
| Nivel del dato | Ejemplos | Dónde puede procesarse |
|---|---|---|
| Público o de bajo riesgo | Textos de marketing, FAQ públicas, descripciones de producto | API en la nube (OpenAI, Gemini, Claude) sin problema |
| Interno con datos personales | Correos de clientes, tickets de soporte, leads del CRM | API en la nube con contrato de tratamiento y anonimización previa |
| Confidencial o regulado | Historiales médicos, contratos, datos financieros sensibles | Modelo local, sin salida a internet |
La regla práctica es sencilla: si el dato no puede salir del edificio por contrato, por normativa o por sentido común, no sale. Y ahí es donde entra un modelo local corriendo en tu propio hardware. Monté justamente eso en el proyecto EVA con modelos locales: un asistente que funciona con modelos que se ejecutan en la máquina del cliente, sin enviar nada a una API externa. Es más lento de configurar y exige una GPU decente, pero garantiza que ningún prompt viaja a un tercero. Para un despacho, una clínica o una empresa con datos regulados, ese requisito no es negociable.
Cuando el dato sí puede salir, las APIs de OpenAI o Gemini son más baratas de arrancar y más potentes de serie. La decisión no es ideológica, es de cumplimiento y de coste. Dejo claro esto en cada proyecto de automatización de procesos con IA que arranco, porque condiciona todo lo demás.
El caso más rentable suele ser un asistente que responde preguntas usando tu documentación, no el conocimiento genérico del modelo. La técnica se llama RAG (recuperación aumentada): el modelo no inventa, busca en tus manuales, tu web o tu base de conocimiento y responde con lo que encuentra. Así construí WWBot, un bot conversacional para WordPress y WooCommerce, que atiende consultas sobre el catálogo y el contenido real de la tienda, y también Agent AI, un agente que opera sobre información concreta en lugar de improvisar.
Aquí el dato que sale es la pregunta del usuario y el fragmento de documentación relevante. Si tu documentación es pública, riesgo bajo. Si contiene procedimientos internos, o anonimizas antes de enviar, o pasas a modelo local.
Un modelo lee cada correo o formulario que entra, lo clasifica (comercial, soporte, spam, urgente) y lo enruta al departamento o a la persona correcta. Puede incluso redactar un primer borrador de respuesta que un humano revisa antes de enviar. El ahorro no está en la redacción, está en no leer manualmente cien correos para ordenarlos.
El dato que sale es el cuerpo del correo, que casi siempre lleva datos personales. Recomiendo procesar solo el texto necesario para clasificar y no almacenar el contenido en el proveedor. Con la configuración de API adecuada, los prompts no se usan para entrenar el modelo.
Facturas, albaranes, contratos y formularios en PDF son el terreno donde la IA paga sola. El modelo lee el documento, extrae los campos (proveedor, importe, fecha, líneas de detalle) y los vuelca a tu ERP o a una hoja de cálculo. Se acaba el picar datos a mano. Lo desarrollo con frecuencia y lo cuento en detalle en el artículo sobre cómo automatizar facturas y albaranes con IA.
El documento suele contener datos fiscales sensibles. Si la empresa lo permite, se procesa vía API con las garantías del proveedor. Si es un despacho contable con datos de terceros, valoro modelo local o un procesado híbrido donde solo salen los campos ya anonimizados.
Actas de reunión, informes largos, hilos de correo interminables: un modelo los resume en un párrafo accionable con las decisiones y los pendientes. También genera borradores de contenido repetitivo, como descripciones de producto a partir de una ficha técnica. El humano sigue teniendo la última palabra, pero parte de un borrador en lugar de una página en blanco.
Aquí el riesgo depende del contenido. Un acta de reunión estratégica no debería salir a una API pública; un borrador de descripción de producto, sí.
En vez de buscar por palabra exacta en carpetas y wikis, el empleado pregunta en lenguaje natural y el sistema encuentra el documento correcto aunque no use las mismas palabras. Es especialmente útil en empresas con años de documentación acumulada donde nadie recuerda dónde está cada cosa. Técnicamente es primo hermano del caso 1: embeddings, una base vectorial y el modelo por encima.
El contenido indexado es interno por definición, así que este caso pide una atención especial al almacenamiento de los embeddings y, en muchos casos, un despliegue cerrado.
Un agente que conversa con el lead, hace las preguntas de cualificación, recoge la información y la deja estructurada en el CRM para que el comercial llame ya sabiendo con quién habla. No sustituye al vendedor, le quita el trabajo administrativo previo y filtra a quien no encaja.
El dato es de contacto comercial, nivel intermedio. Contrato de tratamiento con el proveedor y limpieza de lo que se guarda.
Ningún caso de estos vive aislado. Un modelo de lenguaje sin conexión a tus sistemas es una curiosidad; el valor aparece cuando lo conecto a tu CRM, tu ERP, tu correo o tu web. Trabajo sobre todo con Laravel, Node y Python, y esa parte de fontanería, leer de una fuente, llamar al modelo, validar la respuesta y escribir el resultado en tu sistema, es donde de verdad se gana o se pierde el proyecto. Un modelo puede alucinar; mi trabajo es poner las validaciones, los reintentos y los controles para que un dato inventado nunca acabe en tu factura. Si quieres ver las áreas técnicas que cubro, están en la página de conocimientos y stack.
El orden que sigo es siempre el mismo: primero elijo un caso de uso acotado y medible, no "toda la empresa de golpe"; segundo, clasifico los datos y decido nube o local; tercero, monto un piloto pequeño que puedas probar en semanas, no en meses; y cuarto, si funciona, lo escalo. Este enfoque de alcance medido es el que explico en cómo trabajo, y evita el error clásico de gastarse el presupuesto en una plataforma enorme que nadie usa.
Un piloto de un caso concreto, por ejemplo el triaje de correo o la extracción de facturas, suele arrancar en el rango de las decenas de horas de trabajo, no cientos. Un asistente de soporte con RAG sobre tu documentación es algo más, según el volumen y la limpieza de esa documentación. El coste recurrente de las APIs de OpenAI o Gemini para un uso de PYME suele ser modesto, del orden de unas pocas decenas de euros al mes; un modelo local no tiene coste por uso pero exige hardware y algo más de configuración inicial. Doy los detalles y los rangos en la página de tarifas, siempre orientativos hasta ver tu caso concreto.
Integrar IA en tu empresa no empieza eligiendo entre OpenAI, Gemini o Claude, empieza eligiendo una tarea que hoy te cuesta horas y decidiendo qué datos pueden salir. Con esas dos decisiones tomadas, el resto es ingeniería: conectar el modelo a tus sistemas, validar sus respuestas y medir el ahorro real. Empieza por un caso pequeño, mídelo, y escala solo lo que funcione. Si quieres que revisemos juntos cuál de estos seis casos encaja mejor en tu operativa, escríbeme y lo vemos desde tu formulario de contacto.
Empieza por una sola tarea repetitiva y medible, como clasificar correos o extraer datos de facturas, no por toda la empresa de golpe. Elige el caso, clasifica qué datos maneja y monta un piloto pequeño que puedas probar en semanas. Si funciona, lo escalas; si no, apenas has arriesgado presupuesto.
Depende del dato. Con la configuración de API adecuada, los prompts no se usan para entrenar el modelo y puedes firmar un contrato de tratamiento. Aun así, los datos confidenciales o regulados (historiales médicos, contratos, datos financieros sensibles) no deberían salir a una API externa: para esos casos uso un modelo local que se ejecuta en tu propio hardware.
Conviene un modelo local cuando el dato no puede salir del edificio por normativa, por contrato o por sentido común. El modelo se ejecuta en tu propia máquina y ningún prompt viaja a un tercero. A cambio exige hardware con GPU y más configuración inicial, pero garantiza que la información confidencial nunca abandona tu infraestructura.
Un piloto de un caso concreto suele arrancar en el rango de decenas de horas de trabajo, no cientos, y el coste recurrente de las APIs para un uso de PYME suele ser de unas pocas decenas de euros al mes. Un modelo local no tiene coste por uso pero exige hardware. Los rangos orientativos están en la página de tarifas y se concretan al ver tu caso.
Si tienes un problema parecido y quieres una opinión técnica, cuéntamelo. Te respondo en menos de 24 h laborables.
