Cómo añadir funciones de IA a tu app

Para añadir funciones de IA a tu app, llama a una API de modelo de lenguaje (LLM) desde tu servidor: envíale instrucciones claras junto con los datos relevantes y usa lo que devuelva. La mayoría de las funciones útiles siguen uno de cuatro patrones (resumir, chatear, extraer datos estructurados y clasificar), y cada uno son unas pocas decenas de líneas de código que un creador de apps con IA puede escribir por ti. Lo que decide si la función merece la pena es lo que rodea a la llamada: mantener la clave de API en el servidor, controlar el coste por usuario y revisar la salida antes de confiar en ella.

Los cuatro patrones detrás de la mayoría de funciones de IA

La extracción y la clasificación suelen ser las más valiosas y las menos visibles. Ahorran discretamente unos minutos a alguien con cada registro, y como la salida tiene una forma fija, puedes comprobarla automáticamente. El chat es lo más visible, pero también lo más difícil de hacer bien, y tiene su propia guía: cómo crear una app de chatbot con IA.

Cómo encaja en tu app

Cada patrón tiene la misma estructura:

1. El usuario actúa: pulsa «Resumir», sube un archivo o envía un mensaje.
2. Tu frontend llama a tu propio servidor, no al proveedor de IA.
3. Tu servidor construye la petición: instrucciones del sistema, la entrada del usuario y los datos que el modelo necesite de tu base de datos, solo los que este usuario tiene permiso para ver.
4. Tu servidor llama a la API del LLM con una clave guardada en una variable de entorno.
5. Tu servidor comprueba la respuesta: JSON válido, una etiqueta conocida, una longitud razonable, y luego la guarda o la devuelve.
6. El frontend la muestra, con streaming de texto a medida que llega en las respuestas largas.

La clave está en el servidor en el paso 4 y nunca llega al navegador. Si la idea de una API te resulta nueva, qué es una API es una introducción breve, y cómo usar APIs de LLM explica con más detalle los tokens, los modelos y las claves.

Elegir proveedor y modelo

Los principales proveedores (OpenAI, Anthropic, Google y otros) ofrecen APIs de texto con estructuras bastante parecidas. Preguntas útiles a la hora de elegir:

• Calidad en tu tarea. Prueba unos cuantos ejemplos reales de tu app con dos o tres modelos. Las diferencias suelen ser más claras con tus datos que con los benchmarks generales.
• Tamaño frente a coste. Los proveedores ofrecen modelos más grandes y capaces, y otros más pequeños, baratos y rápidos. La clasificación y la extracción sencilla suelen funcionar bien con un modelo pequeño; el razonamiento largo o la redacción matizada pueden necesitar uno grande.
• Salida estructurada. Para extraer y clasificar, prefiere una función de la API que haga que el modelo devuelva JSON conforme a un esquema que tú le proporcionas, en lugar de analizar texto libre.
• Tratamiento de datos. Lee las condiciones del proveedor sobre si los datos de entrada se almacenan o se usan para entrenar, y si eso encaja con los datos que te dan tus usuarios.
• Límites. Las cuentas nuevas suelen tener límites de frecuencia más bajos; compruébalos antes del lanzamiento.

Los nombres de los modelos y los precios cambian con frecuencia, así que el código debería leer el nombre del modelo de la configuración en lugar de escribirlo a mano en muchos sitios.

Añadir una función, paso a paso

Tomemos un ejemplo concreto: un CRM pequeño en el que cada contacto tiene un historial largo de notas.

1. Guarda la clave. Crea una clave en el panel de tu proveedor y guárdala como secreto del servidor, por ejemplo OPENAI_API_KEY o ANTHROPIC_API_KEY.

2. Pide una funcionalidad concreta:

Añade un botón «Resumir» en la página del contacto. En el servidor, envía las últimas 20 notas del contacto a [PROVEEDOR] usando el secreto [NOMBRE_VARIABLE], con instrucciones para escribir tres viñetas: estado actual, preguntas abiertas y siguiente paso. Incluye solo las notas que el usuario conectado puede ver. Muestra un estado de carga, guarda el resumen con una fecha y hora, y muestra «No se ha podido resumir en este momento» si la llamada falla. Nunca envíes la clave al navegador.

3. Añade extracción donde ahorre tiempo de escritura:

Cuando un usuario pegue una firma de correo en el cuadro «Alta rápida», llama a [PROVEEDOR] en el servidor y devuelve JSON con nombre, empresa, cargo, correo electrónico y teléfono, usando la función de salida estructurada del proveedor. Valida el JSON en el servidor, rellena con él el formulario de nuevo contacto y deja que el usuario lo edite antes de guardar. Deja los campos en blanco en lugar de adivinar.

Lo importante es «deja que el usuario lo edite antes de guardar»: el modelo propone, la persona decide.

4. Clasifica en segundo plano:

Cuando llegue un nuevo ticket de soporte, clasifícalo en exactamente una de estas categorías: facturación, error, solicitud de funcionalidad, acceso a la cuenta, otros. Usa un modelo pequeño y de bajo coste. Si la respuesta no es una de esas etiquetas, guarda «otros». Muestra la etiqueta como una etiqueta editable.

5. Prueba con datos reales y desordenados: notas largas, notas vacías, otros idiomas, una firma sin teléfono, y revisa veinte resultados uno al lado del otro antes de publicar.

Escribir instrucciones que funcionen

Las instrucciones que envías con cada petición (a menudo llamadas prompt del sistema) son donde está la calidad.

• Di para quién es y qué es un buen resultado. «Los resúmenes los lee un vendedor en 10 segundos antes de una llamada» le da al modelo un objetivo.
• Fija el formato. Número exacto de viñetas, límite de longitud, campos, etiquetas.
• Indica qué hacer si no está seguro. «Si las notas no mencionan un siguiente paso, escribe "No hay siguiente paso registrado".» Esto reduce las respuestas inventadas.
• Da dos o tres ejemplos de buena entrada y buena salida para la extracción y la clasificación.
• Separa las instrucciones del contenido del usuario y etiqueta claramente el contenido del usuario, para que el modelo distinga ambas cosas.

Guarda los prompts en archivos dentro de tu código para que estén versionados y se puedan revisar como cualquier otro código.

Controlar los costes

Las APIs de LLM cobran por tokens (pequeños fragmentos de texto), tanto por lo que envías como por lo que devuelven. El coste crece con la cantidad de contexto por petición multiplicada por la frecuencia con la que se ejecuta. Controles prácticos:

• Envía solo lo necesario. Las últimas 20 notas, no todo el historial. Recorta los documentos largos o divídelos.
• Usa el modelo más pequeño que haga el trabajo. Prueba antes de elegir el más grande por defecto.
• Limita la longitud de la salida con el parámetro de máximo de tokens de la API.
• Guarda los resultados en caché. Almacena un resumen y regenéralo solo cuando cambie el origen, en lugar de hacerlo en cada visita a la página.
• Limita por usuario. Un tope diario por cuenta o por plan evita que un usuario muy activo, o un script, dispare la factura.
• Aplica límites de frecuencia al endpoint como a cualquier otra ruta costosa.
• Configura un presupuesto o una alerta en el panel del proveedor y revisa el uso cada semana tras el lanzamiento.
• Registra el consumo de tokens por función para saber cuánto cuesta cada una.

Si las funciones de IA son el centro de tu producto, incluye su coste de funcionamiento en tu precio en lugar de asumirlo sin más.

Seguridad y confianza

La salida de la IA es probabilística. Puede equivocarse aun sonando segura de sí misma, y puede desviarse por el texto que lee. Constrúyelo teniendo eso en cuenta:

• Trata la salida como entrada no confiable. Valida la estructura, escápala antes de mostrarla como HTML y nunca la ejecutes como código ni como consultas a la base de datos.
• Mantén a una persona en el proceso para cualquier cosa con consecuencias: enviar un correo, cambiar un registro, reembolsar un pago. El modelo redacta; una persona confirma.
• Protégete contra la inyección de prompts. Un documento o un mensaje puede contener texto como «ignora tus instrucciones». Limita lo que el modelo puede ver a lo que el usuario actual puede ver, y no le des herramientas que puedan realizar acciones sensibles sin que tu código compruebe primero los permisos.
• Etiqueta el contenido de IA para que los usuarios sepan que un resumen o una sugerencia se ha generado y puedan comprobarlo.
• Gestiona bien los fallos. Los proveedores tienen caídas y límites de frecuencia. Pon tiempos de espera, muestra un mensaje claro y deja que el resto de la app siga funcionando.
• Vigila lo que envían los usuarios. En los campos de texto libre, considera un paso de moderación y explica en tu política de privacidad que el contenido lo procesa un proveedor de IA externo.

La lista completa de comprobaciones está en la lista de seguridad para apps creadas con IA.

Errores habituales

• Empezar con un chatbot general cuando un solo botón de «Resumir» o «Categorizar» ayudaría a más personas.
• Poner la clave en el código del frontend o en un repositorio público.
• Enviar toda la base de datos como contexto, lo que es lento, caro y expone los datos de otros usuarios.
• Confiar en una salida de texto libre cuando un esquema o un conjunto fijo de etiquetas la haría comprobable.
• No tener límites por usuario, y descubrirlo cuando llega la primera factura.

Añadir funciones de IA con Mythex

En Mythex añades IA dentro de tu propia app pidiéndolo en el chat, usando tu propia clave del proveedor. Guarda la clave como secreto del proyecto: cuando el agente la necesite, Mythex muestra en el chat una tarjeta de secretos para que no tengas que pegar la clave en la conversación. Después, el agente escribe la ruta del servidor, los prompts y la interfaz. El uso de IA de tu app lo factura tu proveedor, por separado de los créditos de Mythex que gastas al crear. En la documentación tienes un prompt de inicio en añadir funciones de IA con tus propias claves de API.

Preguntas