La IA como herramienta, no como funcionalidad
Los modelos de lenguaje están cambiando cómo se construye software. Dónde se ganan su sitio de verdad, dónde no, y cómo los integramos con seguridad.
Añadir “IA” a un producto se ha convertido en el movimiento por defecto. Un chat en una esquina, un botón de “generar” en la barra de herramientas, una nota de prensa con la palabra inteligente. Muy a menudo es el movimiento equivocado — no porque la tecnología sea débil, sino porque se ha añadido como funcionalidad en lugar de usarse como herramienta.
La diferencia importa. Una funcionalidad es algo que añades para parecer actual. Una herramienta es algo que eliges porque es la mejor forma de resolver un problema concreto. Los modelos de lenguaje son una herramienta extraordinaria. Como funcionalidad, son mediocres.
En qué son buenos de verdad los modelos
Después de un tiempo construyendo con ellos, aparece un patrón claro. Los modelos de lenguaje son excelentes en un puñado de cosas que antes eran dolorosamente difíciles con código normal:
- Convertir entradas desestructuradas en datos estructurados. Emails, PDFs, formularios escaneados, notas en texto libre — en campos limpios que una base de datos puede usar.
- Buscar por significado en lugar de por palabras clave. Encontrar la cláusula del contrato que significa “rescisión por conveniencia”, aunque nunca use esas palabras.
- Redactar borradores. Primeras versiones de respuestas, resúmenes, descripciones e informes que luego una persona revisa y edita.
- Hacer de pegamento. Una interfaz flexible entre sistemas que nunca se diseñaron para hablar entre sí, o entre una persona y un sistema difícil de consultar.
- Triaje. Leer un gran volumen de elementos entrantes y decidir cuáles necesitan atención primero.
Cuando un problema se parece a uno de estos, un modelo puede sustituir semanas de reglas frágiles — ese código de expresiones regulares y condicionales que se rompe en cuanto un proveedor cambia el formato de su factura — por algo que simplemente funciona, y que sigue funcionando cuando la entrada cambia.
Dónde el código normal sigue siendo la respuesta
La otra cara es igual de importante. Los modelos son probabilísticos. Aciertan la mayoría de las veces, y la proporción exacta depende de la tarea, de los datos y de lo bien construido que esté el sistema a su alrededor. Para muchos problemas, “la mayoría de las veces” es un riesgo.
Fig. 1 — Una forma sencilla de decidir. Cuanto más ambigua es la entrada y más barato es un error, más se gana su sitio un modelo.
Si la tarea tiene que ser exacta, auditable y repetible siempre — calcular una factura, aplicar permisos, mover dinero — el código normal sigue siendo la mejor respuesta. Un modelo que acierta el 98% de las veces es un riesgo en un sistema de facturación. En una bandeja de entrada es un superpoder.
Los casos interesantes están en la esquina superior derecha: entradas ambiguas y errores caros. Revisar contratos, resumir notas clínicas, detectar fraude. Los modelos también son útiles ahí, pero solo como asistentes: redactan, señalan y priorizan; decide una persona.
Integrarla con seguridad
La demo de una funcionalidad con IA es fácil. La versión en producción es donde está el trabajo. Una llamada a un modelo es una dependencia con modos de fallo poco habituales: puede ser lenta, puede equivocarse con total seguridad y su comportamiento puede cambiar cuando el proveedor la actualiza. Así que la tratamos como cualquier otra dependencia crítica — con estructura a su alrededor.
Fig. 2 — La forma que toman la mayoría de nuestras integraciones de IA. El modelo es una pieza más, no todo el sistema.
En la práctica, eso significa unas cuantas cosas innegociables:
- Salida estructurada, siempre validada. Pedimos al modelo los datos en un formato estricto y los comprobamos contra un esquema y contra las reglas de negocio antes de que nada más los toque. Una salida inválida nunca llega al usuario.
- Un plan alternativo para cada llamada. Cuando la validación falla o la confianza es baja, el sistema se degrada con elegancia: una regla más simple, un reintento con más contexto o una cola de revisión humana.
- Un conjunto de evaluación con casos reales. Antes de lanzar, y cada vez que algo cambia, el sistema se puntúa contra un conjunto de ejemplos reales y representativos con respuestas correctas conocidas. “Cuando lo probé parecía bien” no es un test.
- Personas donde hay mucho en juego. Para las decisiones que importan, el modelo prepara y la persona aprueba. La interfaz está pensada para que revisar sea rápido, no para ocultar que ha intervenido un modelo.
- Costes y latencia en el panel. Las llamadas a modelos cuestan dinero y tiempo. Medimos ambos desde el primer día, para que no haya sorpresas cuando crezca el uso.
Nada de esto es vistoso. Es la diferencia entre una funcionalidad de IA que impresiona en una reunión y una que, en silencio, le ahorra horas a un equipo cada semana durante años.
Cómo decidimos
Tratamos la IA como cualquier otra parte del stack: tiene que justificar su coste, su latencia y sus modos de fallo frente a la alternativa más sencilla. A veces la alternativa más sencilla es una regla bien escrita y una consulta a base de datos. A veces es un modelo haciendo algo que ninguna cantidad de reglas podría hacer.
La pregunta que nos hacemos nunca es “¿dónde podemos meter IA?”. Es “¿cuál es la forma más fiable de resolver este problema?” — y después elegimos la herramienta.
Si te preguntas si la IA tiene sentido en tu proyecto, escríbenos. A veces la respuesta más útil que podemos darte es “todavía no” — y a veces es “sí, y así es como se hace bien”.