# Cómo añadir IA a una aplicación web existente

> Empieza por un trabajo que un usuario ya hace a mano, ancla el modelo en datos que ya tienes, y fija presupuestos de precisión, latencia y coste antes de escribir código. Publícala detrás de un feature flag para un grupo pequeño, mide contra esos presupuestos y luego amplía. El trabajo de integración, no el modelo, es lo que lleva el tiempo.

La mayoría de los equipos que hacen esta pregunta ya tienen las partes difíciles. Hay una base de datos con datos reales, un sistema de autenticación, un pipeline de despliegue, y usuarios que se darán cuenta si algo se rompe. Es una posición de partida mucho mejor que un proyecto de IA desde cero, y cambia el orden en el que debería hacerse el trabajo.

## ¿Qué funcionalidad deberías construir primero?

Elige un trabajo que alguien ya hace a mano, una y otra vez, dentro de tu producto. Agentes de soporte que pegan la misma explicación. Operaciones que leen PDFs y copian cinco campos a un formulario. Usuarios que recorren una lista porque la búsqueda solo coincide con palabras exactas.

Esas son buenas primeras funcionalidades por tres razones. El valor es medible, porque sabes más o menos cuántos minutos tarda la versión manual. Los datos de entrenamiento ya existen, en forma de lo que esas personas hicieron el mes pasado. Y la definición de "correcto" la tiene alguien en el edificio, que es lo que vas a necesitar enseguida.

Evita, como primera funcionalidad, cualquier cosa cuya salida vaya directa a un cliente sin revisión, cualquier cosa que cruce más de dos sistemas, y cualquier cosa en la que nadie sepa cómo se ve una buena respuesta.

## Por qué el anclaje importa más que el modelo

Un modelo general sabe mucho del mundo y nada de tu negocio. Pregúntale por tu política de reembolsos y producirá algo que suena a política de reembolsos, lo cual es peor que inútil.

El anclaje es la solución: recupera el texto relevante de tus propios sistemas, ponlo en el prompt e indica al modelo que responda solo a partir de él. Esto es generación aumentada por retrieval, y es donde de verdad va el esfuerzo de ingeniería.

En la práctica eso significa decidir qué es una unidad recuperable (un documento suele ser demasiado grande, una frase demasiado pequeña, una sección aproximadamente bien), mantener un índice buscable de esas unidades junto a los registros de origen, y pasar al modelo el puñado más relevante para la pregunta junto con de dónde sale cada uno, para que la respuesta pueda citarlos.

Tu base de datos actual suele bastar para empezar. Postgres con `pgvector`, o incluso búsqueda de texto completo, lleva una primera funcionalidad más lejos de lo que los equipos esperan. Una base de datos vectorial dedicada es una decisión de escala, no un requisito de partida.

## ¿Qué presupuestos deberías fijar antes de escribir código?

Tres cifras, acordadas antes de implementar, porque cada una cambia el diseño:

**Precisión.** Reúne de treinta a cincuenta ejemplos reales con respuestas conocidas, y decide qué porcentaje debe acertar para que valga la pena publicar la funcionalidad. Treinta ejemplos en una hoja de cálculo son un conjunto de evaluación perfectamente respetable, y son treinta más de los que tiene la mayoría de los equipos.

**Latencia.** Un cuadro de búsqueda tiene que sentirse instantáneo; un pipeline nocturno de documentos no. Esa sola decisión determina si puedes permitirte un modelo grande, si necesitas streaming, y si el trabajo pertenece a una cola.

**Coste por llamada.** Multiplica el recuento esperado de tokens por el precio del proveedor, y luego por el volumen mensual esperado. Hazlo en una servilleta antes de construir, porque es la cifra más probable de matar la funcionalidad más adelante, y el diseño que la arregla (un modelo más pequeño, retrieval en caché, un filtro barato de primer paso) es mucho más fácil de adoptar al principio.

## ¿Cómo la publicas sin poner en riesgo el producto?

Ponla detrás de un flag y actívala para un puñado de usuarios que saben que van pronto. Registra cada petición y cada respuesta, incluido el contexto recuperado, para que cuando alguien reporte una mala respuesta puedas ver exactamente qué estaba mirando el modelo.

Mantén a una persona en el bucle en cualquier sitio donde la funcionalidad escriba, envíe o gaste. Un agente que redacta y pide aprobación es casi tan útil como uno que actúa solo, y falla con mucha más gracia.

Luego compara con los presupuestos que fijaste. Si la precisión se queda corta, el arreglo casi siempre es la retrieval y no el prompting: el modelo suele no poder ver el texto correcto. Si el coste se queda corto, mira cuánto contexto estás enviando antes de mirar cualquier otra cosa.

## Dónde va de verdad el tiempo

Los equipos esperan de forma consistente que el trabajo del modelo domine, y descubren que no es así. En una primera funcionalidad típica, el diseño del prompt son unos días. La retrieval (decidir qué indexar, mantenerlo sincronizado cuando cambian los registros, hacer buenos los resultados) son un par de semanas. La evaluación, la interfaz, los permisos, los estados de error, el logging y el despliegue son el resto.

Es un proyecto de software normal con un componente inusual en el medio, y eso es una buena noticia: significa que tu práctica de ingeniería actual aplica en su mayor parte. Las partes que son de verdad nuevas son el conjunto de evaluación y el hábito de tratar el modelo como poco fiable por defecto.

## La secuencia, condensada

1. Elige un trabajo repetitivo dentro del producto.
2. Escribe treinta ejemplos reales y sus respuestas correctas.
3. Fija presupuestos de precisión, latencia y coste.
4. Construye retrieval sobre datos que ya tienes.
5. Publícala detrás de un flag para un grupo pequeño, registrándolo todo.
6. Mide contra los presupuestos, arregla primero la retrieval, amplía.

Nada de esto exige una migración de plataforma, un equipo nuevo ni un deck de estrategia. Exige elegir algo lo bastante pequeño para terminarlo y ser honesto sobre si funciona.

---

Publicado por Vuewer. Funciones de IA y aplicaciones web, llevadas a producción.
Versión canónica: https://vuewer.com/es/blog/como-anadir-ia-a-una-aplicacion-web-existente