Integrar IA en tu automatización

Hasta aquí, en el nivel 3 has aprendido qué es la automatización, cómo funcionan Zapier y n8n y cómo los webhooks mandan datos de A a B. Lo que faltaba es el puente. Todos esos flujos mueven datos y siguen reglas fijas. Si esto, entonces aquello. Pero en cuanto la tarea necesita algo de comprensión, clasificar un correo, resumir un texto, convertir un formulario caótico en campos limpios, la lógica pura de si-entonces llega a su límite. Justo ahí metes un modelo de lenguaje en medio de tu flujo. Ese es el paso que convierte la automatización en automatización con IA, y para eso no necesitas código.

Imagínate un caso típico. Te llegan solicitudes de contacto por un formulario. Algunas son consultas reales de clientes, otras son spam, otras son candidaturas. Una automatización clásica no las puede distinguir, porque la diferencia está en el texto y no en un campo fijo. Un modelo de lenguaje sí. Le mandas al modelo el texto de la solicitud, le preguntas "¿esto es una consulta de cliente, spam o una candidatura?, responde solo con una palabra", y enrutas según eso. Esa es la idea en una frase.

Dónde se sitúa el modelo dentro del flujo

En cualquier plataforma no-code la estructura es la misma. Tienes un disparador, después varios pasos, al final una acción. El modelo de lenguaje es sencillamente uno de esos pasos intermedios. Antes viene el disparador, la entrada del formulario. Después viene la acción, el correo o la entrada en la base de datos. El modelo se sienta en medio y convierte una entrada sin estructura en una decisión o en una salida limpia.

Hay dos formas de hablar con el modelo. La cómoda es una pieza ya hecha. n8n tiene un nodo de IA, Zapier tiene una integración de IA, y las dos te dejan elegir proveedor directamente, escribir un prompt y usar el resultado en el paso siguiente. La flexible es el nodo de petición HTTP que ya conoces de la lección de webhooks. Con él llamas directamente a la API del proveedor. Es exactamente el mismo principio que un webhook, solo que el receptor es un modelo de lenguaje.

La llamada directa a la API

Si vas por la vía HTTP, construyes una petición POST de lo más normal. Con la Messages API de Anthropic se hace así. Necesitas tres cabeceras y un cuerpo.

POST https://api.anthropic.com/v1/messages

Header:
  x-api-key: TU_API_KEY
  anthropic-version: 2023-06-01
  content-type: application/json

La cabecera anthropic-version es fija y se queda en 2023-06-01, esa es la versión de la API y no tiene nada que ver con la fecha de hoy. La x-api-key la sacas de la cuenta de tu proveedor. Trátala como una contraseña, no va nunca en un formulario público ni en un flujo compartido.

Como mínimo el cuerpo se ve así:

{
  "model": "claude-haiku-4-5",
  "max_tokens": 200,
  "messages": [
    {
      "role": "user",
      "content": "Clasifica esta solicitud en exactamente una categoria: consulta de cliente, spam o candidatura. Responde solo con la palabra de la categoria. Solicitud: {{texto_formulario}}"
    }
  ]
}

El {{texto_formulario}} es un marcador que la plataforma no-code rellena con el contenido real del paso anterior. En n8n eso lo escribes como expresión, en Zapier arrastras el campo con un clic. La respuesta del modelo queda después en un campo que usas en el paso siguiente, por ejemplo para decidir con un filtro si el correo va a ventas o a la carpeta de spam.

Una palabra sobre la elección de modelo, que te ahorra dinero contante. Para clasificación sencilla y reformateo coges el modelo más barato, o sea Haiku 4.5. Es rápido y cuesta casi nada por llamada. Para tareas que necesitan comprensión de verdad, como resumir una solicitud con tus propias palabras, coges Sonnet 5. Opus casi nunca lo necesitas en un flujo de automatización, sería matar moscas a cañonazos.

Respuestas estructuradas en vez de texto corrido

El error de principiante más habitual es dejar que el modelo responda libremente y luego confiar en que el formato encaje. Unas veces responde "Esto es una consulta de cliente", otras "Categoría: consulta de cliente", otras con un párrafo entero. Tu automatización no puede hacer nada con eso porque el paso siguiente espera una palabra exacta.

La solución es decirle al modelo en el prompt exactamente cómo tiene que ser la respuesta. "Responde solo con la palabra de la categoría, sin frase, sin punto." Queda todavía más limpio si exiges JSON:

{
  "model": "claude-haiku-4-5",
  "max_tokens": 300,
  "messages": [
    {
      "role": "user",
      "content": "Extrae de este texto nombre, email y peticion. Responde exclusivamente como JSON con los campos nombre, email, peticion. Texto: {{texto_formulario}}"
    }
  ]
}

El JSON es tan práctico porque la mayoría de herramientas no-code lo pueden descomponer directamente en campos sueltos. De la salida del modelo {"nombre": "Ana", "email": "ana@...", "peticion": "presupuesto"} salen tres campos limpios que usas por separado. Con eso has convertido un formulario de texto libre y caótico en datos estructurados, y eso antes era imposible con lógica pura de si-entonces.

Qué puede salir mal

Tres trampas de la práctica.

Primera, el modelo no siempre respeta el formato. Incluso con una instrucción clara, de vez en cuando se cuela una frase de más. Monta un paso de seguridad que compruebe si la respuesta es de verdad una de tus palabras esperadas, y manda todo lo demás a una revisión manual en vez de seguir procesándolo a ciegas.

Segunda, costes que suben sin que te des cuenta. Un flujo que llama a un modelo en cada solicitud de formulario es barato. Un flujo que corre en bucle y llama al modelo mil veces te puede sorprender. Mira el consumo en la cuenta del proveedor después del primer día, antes de poner el flujo en producción.

Tercera, la API key en el campo equivocado. He visto flujos en los que la key acabó sin querer en un campo de salida que después aparecía en un correo. La key va en la gestión de credenciales de la plataforma, nunca en el texto del prompt y nunca en un campo que salga hacia fuera.

Qué sigue

Ya sabes poner un modelo de lenguaje como paso en medio de tu automatización, sea con un nodo de IA ya hecho o con una llamada HTTP directa, y sabes cómo conseguir respuestas estructuradas y limpias. Esa es la base de casi cualquier flujo de IA útil. En la próxima lección, el capstone del nivel 3, construyes un flujo completo desde el disparador hasta la acción con un modelo en medio. Si quieres dejar asentar otra vez la parte de HTTP, vuelve a leer la lección de webhooks de este nivel, el principio es idéntico.

Source

• Referencia de la Messages API: https://platform.claude.com/docs/en/api/messages
• Modelos y precios: https://platform.claude.com/docs/en/about-claude/models/overview