Cómo integrar IA en tu software sin tener que reescribirlo

Pongamos el caso de una comercializadora de material eléctrico que tiene un sistema interno hecho hace varios años. No es bonito, pero funciona: ahí viven los clientes, los pedidos, el inventario y las cotizaciones. Un día el dueño ve una demo de IA, le pregunta a un proveedor cómo tener algo así y la respuesta es: “hay que migrar todo a una plataforma nueva”.

Casi nunca hace falta.

Un modelo de lenguaje, para efectos prácticos, es otro servicio al que tu sistema le manda una petición y del que recibe una respuesta. Igual que hoy tu software le habla al PAC para timbrar una factura o a la pasarela para cobrar con tarjeta. Lo difícil no es la llamada. Lo difícil es escoger bien dónde ponerla, qué datos mandarle y cómo saber si la respuesta sirve.

Dónde sí encaja la IA dentro de un sistema que ya funciona

La regla que uso es sencilla: busca los lugares donde hay texto desordenado o una decisión repetitiva que hoy hace una persona leyendo. Ahí el modelo aporta. En los cálculos exactos (totales, impuestos, existencias) no le toca; para eso tu sistema ya tiene código que nunca se equivoca en una suma.

• Búsqueda en lenguaje natural: Que alguien escriba “pedidos de Ferretería del Centro del mes pasado que siguen sin pagar” y el sistema lo traduzca a un filtro real sobre tu base de datos, en vez de pelearse con seis menús.
• Resumir y clasificar: Correos de clientes, tickets de soporte, notas de visitas de los vendedores. El modelo los etiqueta (queja, cotización, seguimiento) y deja un resumen de dos líneas.
• Extraer datos de documentos: Órdenes de compra en PDF, constancias, remisiones escaneadas. El modelo lee el documento y devuelve los campos que tu sistema necesita para darlo de alta.
• Sugerencias: Un borrador de respuesta al cliente, el código de producto más probable cuando alguien lo escribe mal, el siguiente paso en un trámite.
• Asistentes dentro del sistema: Un panel al lado del pedido que tienes abierto, que ya sabe de qué cliente se trata y puede contestar preguntas sobre su historial.

Fíjate que ninguno es “un chatbot en la esquina de la pantalla”. Cada uno vive pegado a una pantalla y a un proceso que ya existe. De eso depende casi todo lo demás.

Los caminos técnicos, explicados sin humo

Hay varias formas de conectar un modelo con tu software. No son excluyentes; un proyecto normal termina usando dos o tres.

Llamar a la API de un modelo desde tu backend

Es el punto de partida. Tu servidor arma un mensaje con instrucciones y los datos del caso, lo manda a la API del proveedor (OpenAI, Anthropic, Google, el que sea) y recibe la respuesta. Ojo con el detalle: desde el backend, no desde el navegador. Así la llave de la API no queda expuesta y tú decides exactamente qué información sale de tu sistema.

Pedirle JSON, no prosa

Si el resultado lo va a leer tu código, no quieres un párrafo bonito, quieres campos. Para eso existen las salidas estructuradas. La documentación de OpenAI dice que su modo de Structured Outputs asegura que el modelo siempre genere respuestas que se apeguen al JSON Schema que le das (con una excepción: si el modelo se niega a contestar, lo indica en un campo aparte). Anthropic ofrece algo parecido con su opción de uso estricto de herramientas. En la práctica esto es lo que convierte “la IA leyó el PDF” en “la orden de compra quedó capturada con RFC, partidas y fecha de entrega”.

Dejar que el modelo use funciones de tu sistema

Esto se llama tool calling o function calling. Tú describes funciones (buscar cliente, consultar existencias, crear borrador de cotización) y el modelo decide cuándo usarlas. El detalle importante, y que mucha gente no sabe: el modelo no ejecuta nada por su cuenta. Según la documentación de Anthropic, el modelo regresa una llamada estructurada y es tu aplicación la que la ejecuta y le devuelve el resultado. O sea, tus permisos, tus validaciones y tu bitácora siguen mandando.

MCP, el enchufe estándar

El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA con sistemas externos; su propia documentación lo compara con un puerto USB-C. La ventaja es que expones tus funciones una vez y distintos clientes de IA pueden usarlas. Si quieres el detalle, lo explico en qué es MCP y para qué le sirve a una empresa. Para una primera integración dentro de tu propio sistema, muchas veces basta con tool calling directo.

Modelos locales

También puedes correr un modelo abierto en un servidor tuyo. Tiene sentido cuando la información no debe salir de tu red o cuando el volumen es tan alto que pagar por llamada ya no conviene. A cambio cargas con el hardware, el mantenimiento y, por lo general, con modelos menos capaces que los mejores de la nube. No es mala opción; es otra cuenta.

Antes de escribir una línea de código

Tres cosas tienen que estar más o menos en orden, y si no lo están, ahí es donde conviene empezar.

Datos ordenados. Si el catálogo tiene el mismo producto dado de alta cuatro veces con nombres distintos, la IA va a heredar ese desorden y lo va a repetir con mucha seguridad.

Una forma de leer tu sistema desde código. Idealmente una API; si no existe, al menos acceso de solo lectura a la base de datos o una exportación confiable. Sin eso el modelo no tiene de dónde sacar contexto. Esto da para un tema completo, y lo desarrollé en por qué tener software propio te da ventaja con la IA.

Un proceso que se pueda medir. Cuántos documentos se capturan por semana, cuánto tarda cada uno, cuántos salen con error. Si hoy no tienes ese número, tómalo antes de tocar nada. Después lo vas a necesitar para saber si valió la pena.

Lo que cuesta, en dinero y en segundos

Las APIs de modelos cobran por tokens, que son pedazos de texto: lo que mandas y lo que el modelo genera. Y hay costos que no se ven a primera vista. La documentación de Anthropic aclara que las definiciones de herramientas (nombres, descripciones, esquemas) también cuentan como tokens de entrada en cada petición. Si le describes cuarenta funciones al modelo en cada llamada, eso se paga cada vez.

Con la velocidad pasa algo que sorprende. La guía de latencia de OpenAI explica que recortar a la mitad los tokens de salida puede bajar la latencia cerca de 50%, mientras que recortar a la mitad el prompt quizá solo la mejore entre 1% y 5%. Traducido: pide respuestas cortas y estructuradas. La misma guía recomienda modelos más chicos cuando alcanzan (suelen ser más rápidos y más baratos), mostrar la respuesta conforme se genera y, algo que me gusta mucho, no usar un modelo cuando una regla fija resuelve el caso.

Otra palanca útil es el caché de prompts. Si cada llamada repite las mismas instrucciones largas o el mismo manual, Anthropic cobra las lecturas de caché a una décima parte del precio normal de entrada y reporta mejor tiempo de respuesta en documentos largos. Para un asistente que siempre carga el mismo catálogo, eso se nota en la factura.

¿Cómo sabes si de verdad funciona?

Aquí es donde la mayoría de los proyectos de IA se quedan cojos. Alguien prueba diez ejemplos, se ven bien, se manda a producción y a las tres semanas nadie sabe si está ayudando o estorbando.

Lo que funciona es tratarlo como cualquier otra parte del software: con pruebas. La guía de evaluaciones de Anthropic empieza por ahí, con criterios de éxito específicos y medibles (no “que funcione bien”, sino “que clasifique correctamente el tipo de correo”). Luego pide casos de prueba que se parezcan a lo que de verdad llega, incluyendo los raros: documentos vacíos, textos larguísimos, peticiones ambiguas en las que ni dos personas se pondrían de acuerdo.

Esa misma guía sugiere automatizar la calificación siempre que se pueda y dice algo que a mí me parece muy sensato: es mejor tener muchas preguntas con calificación automática un poco menos fina que pocas revisadas a mano con todo cuidado. La revisión humana no desaparece, se vuelve muestreo. Alguien del equipo revisa cada semana un puñado de resultados al azar, y en lo que mueve dinero o toca a un cliente, una persona aprueba antes de que se ejecute.

Errores que se repiten mucho

El primero es meter un chatbot genérico y llamarle integración. Un asistente que no conoce tus pedidos ni tus clientes contesta cosas que podrías preguntarle a cualquier chat público. Se ve moderno en la demo y en el día a día nadie lo abre.

El segundo es no medir. Ya lo dije arriba, pero lo repito porque es el que más dinero tira: sin línea base y sin casos de prueba, cualquier cambio de modelo o de instrucciones es una apuesta.

El tercero es mandar datos sensibles sin revisar qué sale y a dónde. RFC, datos personales de clientes, expedientes, precios negociados. Antes de conectar nada, revisa qué campos realmente necesita el modelo para la tarea (casi siempre son menos de los que crees), qué dice el contrato del proveedor sobre retención y uso de datos, y si alguna parte debería quedarse en un modelo local. Y dale permisos de escritura poco a poco; que primero sugiera y una persona confirme.

Por dónde empezaría yo

Por un solo proceso, el más repetitivo y fácil de medir que tengas. Y con la solución más simple que lo resuelva. Anthropic, en su guía sobre cómo construir agentes, recomienda justo eso: buscar la solución más sencilla posible y agregar complejidad solo cuando haga falta, empezando muchas veces con una sola llamada bien diseñada al modelo. Primero que capture bien las órdenes de compra; después hablamos del agente que hace todo.

Si tu sistema ya existe y quieres ver por dónde entrarle sin romper lo que funciona, eso es justo lo que hacemos en software a la medida con IA integrada: partir de lo que ya tienes, conectar el modelo donde aporta y dejar las pruebas armadas para que puedas comprobarlo tú mismo.