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 grande (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 son 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 vale la pena es el trabajo alrededor de la llamada: mantener la clave de API en el servidor, controlar el coste por usuario y revisar el resultado antes de fiarte de él.

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 el más visible, pero el 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

Todos los patrones tienen la misma forma:

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 necesita de tu base de datos, solo los datos que este usuario puede 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, transmitiendo el 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 tokens, modelos y claves.

Elegir proveedor y modelo

Los principales proveedores (OpenAI, Anthropic, Google y otros) ofrecen APIs de texto con formas bastante similares. Preguntas útiles al elegir:

• Calidad en tu tarea. Prueba algunos ejemplos reales de tu app con dos o tres modelos. Las diferencias suelen verse más claras con tus datos que en 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 más grande.
• Salida estructurada. Para extracción y clasificación, prefiere una función de la API que haga que el modelo devuelva JSON que cumpla un esquema que tú proporcionas, en lugar de analizar texto libre.
• Tratamiento de datos. Lee las condiciones del proveedor sobre si los datos de la API 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; revísalos antes de un lanzamiento.

Los nombres y precios de los modelos cambian con frecuencia, así que el código debería leer el nombre del modelo desde 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 pequeño CRM donde cada contacto tiene un largo historial 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 marca de tiempo y muestra “No se pudo resumir en este momento” si la llamada falla. Nunca envíes la clave al navegador.

3. Añade extracción donde ahorre escribir:

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 y teléfono, usando la función de salida estructurada del proveedor. Valida el JSON en el servidor, rellena previamente el formulario de nuevo contacto con él 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 opciones: facturación, error, solicitud de función, acceso a la cuenta, otro. Usa un modelo pequeño y de bajo coste. Si la respuesta no es una de esas etiquetas, guarda “otro”. Muestra la etiqueta como una marca editable.

5. Prueba con datos reales y desordenados: notas largas, notas vacías, otros idiomas, una firma sin número de 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.
• Di qué hacer si no está seguro. “Si las notas no mencionan un siguiente paso, escribe ‘No se registró ningún siguiente paso’.” Así se reducen las respuestas inventadas.
• Da dos o tres ejemplos de entrada y salida buenas para extracción y clasificación.
• Mantén las instrucciones separadas del contenido del usuario y etiqueta claramente ese contenido, para que el modelo distinga unas de otro.

Guarda los prompts en archivos dentro de tu código para que tengan versiones y se puedan revisar como cualquier otro código.

Controlar los costes

Las APIs de LLM cobran por tokens (fragmentos pequeños 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 optar por el más grande.
• Limita la longitud de salida con el parámetro de máximo de tokens de la API.
• Guarda los resultados en caché. Almacena un resumen y regenérala solo cuando cambie el origen, en lugar de en cada visita a la página.
• Limita por usuario. Un tope diario por cuenta o por plan evita que un usuario intensivo, o un script, dispare la factura.
• Aplica límites de frecuencia al endpoint como a cualquier ruta costosa.
• Configura un presupuesto o una alerta en el panel del proveedor y revisa el uso semanalmente tras el lanzamiento.
• Registra el uso 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 ser incorrecta sonando segura de sí misma, y puede ser dirigida por el texto que lee. Diseña 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 fue generada y puedan revisarla.
• Gestiona bien los fallos. Los proveedores sufren 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 campos de texto abiertos, considera un paso de moderación e indica en tu política de privacidad que el contenido lo procesa un proveedor externo de IA.

La lista más amplia de comprobaciones está en la lista de seguridad para apps creadas con IA.

Errores habituales

• Empezar con un chatbot general cuando un simple 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 la base de datos entera como contexto, lo que es lento, caro y arriesga exponer los datos de otros usuarios.
• Confiar en salidas de texto libre cuando un esquema o un conjunto fijo de etiquetas las haría comprobables.
• No tener límites por usuario, algo que se descubre cuando llega la primera factura.

Añadir funciones de IA con Mythex

En Mythex puedes añadir IA dentro de tu propia app pidiéndolo en el chat, usando tu propia clave de proveedor. Guarda la clave como secreto del proyecto: cuando el agente la necesite, Mythex muestra una tarjeta de secretos en el chat para que no pegues la clave en la conversación. 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. La documentación incluye un prompt inicial en añadir funciones de IA con tus propias claves de API.

Preguntas