Next.js on KnightLi Blog

Qué es Vercel AI SDK: un toolkit unificado para desarrolladores TypeScript que crean apps de IA

Sun, 17 May 2026 23:07:38 +0800

vercel/ai es el AI SDK open source mantenido por Vercel.

Su posicionamiento es claro: ofrece a los desarrolladores TypeScript un conjunto de herramientas unificado para crear aplicaciones de IA y AI Agents. Viene del equipo detrás de Next.js, pero no se limita a Next.js. También soporta React, Svelte, Vue, Angular y runtimes como Node.js.

Repositorio del proyecto: https://github.com/vercel/ai

Si estás creando una app de chat, una herramienta de escritura con IA, una aplicación RAG, un Agent con tool calling, una interfaz con salida en streaming, o un producto que debe conectar varios proveedores de modelos en la misma aplicación, Vercel AI SDK merece atención.

El problema central que resuelve

Hoy, al crear aplicaciones de IA, uno de los mayores problemas no es “si se puede llamar a un modelo”, sino que cada proveedor tiene APIs, formatos de streaming, convenciones de tool calling, manejo de errores y necesidades de estado en frontend distintas.

Por ejemplo:

OpenAI tiene su propio SDK y formatos de respuesta.
Anthropic tiene su propia estructura de mensajes.
Google, xAI, Mistral, DeepSeek, Groq y otros también difieren.
La salida en streaming requiere manejar chunks.
El tool calling requiere procesar solicitudes estructuradas iniciadas por el modelo.
La UI de chat también debe gestionar mensajes, estados de carga, cancelación, reintentos y errores.

Si escribes un adaptador manual para cada proveedor, el proyecto se vuelve complejo muy rápido.

La idea de Vercel AI SDK es reunir esas diferencias detrás de una API unificada. El desarrollador escribe la aplicación contra una sola interfaz y conecta distintos modelos mediante Providers.

Arquitectura unificada de Providers

Una característica clave de Vercel AI SDK es que es provider-agnostic, es decir, no está atado a un único proveedor de modelos.

Puede acceder a OpenAI, Anthropic, Google y otros proveedores mediante una API unificada. El README del proyecto también indica que AI SDK usa Vercel AI Gateway de forma predeterminada, lo que facilita acceder a varios providers principales.

Esto es útil en proyectos reales.

Muchos productos de IA terminan usando más de un modelo:

Algunas tareas necesitan modelos de razonamiento fuerte.
Algunas tareas necesitan modelos rápidos y baratos.
Algunas tareas requieren multimodalidad.
Algunas tareas requieren contexto largo.
Algunas tareas necesitan modelos locales o privados.

Una arquitectura unificada de Providers facilita el cambio de modelo, las pruebas graduales, el control de costos y las estrategias de fallback.

El streaming es clave para la experiencia frontend

Una gran diferencia entre las apps de IA y las APIs tradicionales es que las respuestas pueden ser largas.

Si el usuario debe esperar a que vuelva toda la respuesta, las herramientas de chat, escritura y programación se sienten lentas. La salida en streaming permite mostrar texto de forma progresiva, para que el usuario vea avance antes.

Vercel AI SDK encapsula bastante bien la generación en streaming. El desarrollador no necesita manejar desde cero eventos de bajo nivel, sino usar las APIs de generación y streaming del SDK para conectar la salida del modelo con la UI.

Esto resulta especialmente cómodo en aplicaciones Next.js / React.

Una interfaz de chat con IA parece simple, pero en realidad debe manejar:

Lista de mensajes.
Entrada del usuario.
Solicitudes al servidor.
Visualización de tokens en streaming.
Estado de carga.
Estado de error.
Cancelación de generación.
Regeneración.

Estas son las tareas repetitivas que AI SDK intenta reducir.

Tool calling y escenarios de Agent

A medida que las aplicaciones de IA pasan de “chatear” a “hacer cosas”, el tool calling se vuelve cada vez más importante.

El modelo no solo devuelve lenguaje natural; también puede necesitar llamar funciones externas:

Consultar una base de datos.
Buscar documentos.
Llamar APIs de negocio.
Leer el estado de un pedido.
Generar gráficos.
Crear eventos de calendario.
Modificar archivos de proyecto.

Vercel AI SDK soporta capacidades de tool calling, para que el desarrollador defina herramientas, parámetros y lógica de ejecución, y el modelo pueda solicitar esas herramientas cuando corresponda.

Esta es una de las razones por las que pasó de ser un “SDK de UI de chat” a un toolkit más amplio para aplicaciones de IA y Agents.

Pero añadir tool calling no lo resuelve todo. En proyectos reales también hay que considerar:

Validación de parámetros.
Límites de permisos.
Logs de llamadas a herramientas.
Idempotencia.
Timeouts y reintentos.
Confirmación humana.
Restricciones para acciones sensibles.

AI SDK puede ayudar con interfaces y flujo, pero los límites de seguridad los debe diseñar el desarrollador.

Integración de UI

Vercel AI SDK es amigable con frameworks frontend.

No solo ofrece APIs centrales de generación; también abstrae chat, completions, estado de mensajes y UI en streaming. Para equipos que usan Next.js y React, esto puede reducir mucho código repetitivo.

Pero no sirve únicamente para despliegues en Vercel.

Si tu proyecto usa TypeScript, o tu backend corre en Node.js, AI SDK puede funcionar como capa de llamada a modelos y procesamiento de streaming. Desplegar o no en Vercel depende de la arquitectura, hábitos del equipo e infraestructura.

Skill for Coding Agents

El README de vercel/ai incluye una sugerencia interesante: si usas coding agents como Claude Code o Cursor, puedes añadir el skill de AI SDK al repositorio.

El comando de ejemplo es:

`1`	`npx skills add vercel/ai`

Esto muestra que Vercel entiende que los usuarios de AI SDK no son solo desarrolladores humanos, sino también coding agents.

Cuando un agent modifica un proyecto que usa AI SDK, un skill dedicado en el repositorio puede ayudarle a entender convenciones del SDK, APIs frecuentes, estructura del proyecto y buenas prácticas, reduciendo la probabilidad de cambios desordenados.

Esta dirección merece seguimiento.

En el futuro, los proyectos open source quizá no solo ofrezcan README y documentación, sino también instrucciones estructuradas para AI coding agents. En SDKs complejos, eso puede convertirse en una nueva puerta de entrada a la experiencia de desarrollo.

Proyectos para los que encaja

Vercel AI SDK encaja en estos escenarios:

Apps de chat con IA basadas en Next.js / React.
Herramientas de escritura, preguntas y respuestas, soporte y asistentes de código que necesitan streaming.
Productos de IA que deben conectar varios model providers.
Equipos que quieren crear prototipos RAG o de preguntas sobre documentos rápidamente.
Apps que necesitan tool calling, function calling o capacidades ligeras de Agent.
Equipos que ya usan TypeScript / Node.js.

Es especialmente útil para desarrolladores frontend y full-stack. En muchas apps de IA, la dificultad no es solo llamar al modelo, sino convertir la salida del modelo en una experiencia estable, fluida e interactiva.

Para qué no encaja tanto

Si tu proyecto es principalmente un backend Python, entrenamiento de deep learning, fine-tuning de modelos o servicio de inferencia de bajo nivel, Vercel AI SDK quizá no sea la herramienta central.

Está más cerca de la capa de aplicación que de un framework de entrenamiento.

Si necesitas:

Entrenar tu propio modelo.
Gestionar clusters de inferencia con GPU.
Hacer batch inference de bajo nivel.
Controlar profundamente tokenizer, KV cache, cuantización y motores de inferencia.

Conviene mirar PyTorch, vLLM, SGLang, TensorRT-LLM, llama.cpp o servicios cloud de inferencia.

Vercel AI SDK se parece más a la capa que conecta capacidades de modelos con productos.

Qué tener en cuenta al usarlo

Primero, no interpretes una API unificada como ausencia total de diferencias.

Los distintos model providers siguen variando en capacidades, longitud de contexto, formatos de tool calling, detalles de streaming, tipos de error y precios. Un SDK unificado reduce fricción de ingeniería, pero no elimina las diferencias entre modelos.

Segundo, controla costos.

Cuando una app de IA sale a producción, el chat en streaming, los reintentos, tool calls, recuperación RAG y fallbacks multi-modelo pueden aumentar costos. Hace falta rate limiting, caché, logs y monitoreo de presupuesto.

Tercero, diseña límites de seguridad.

Si el modelo puede llamar herramientas, debes limitar qué pueden hacer esas herramientas. No dejes que el modelo ejecute directamente acciones de alto riesgo, ni expongas secretos, permisos de escritura en bases de datos u operaciones de producción sin controles.

Cuarto, conserva observabilidad.

Cuando una app de IA falla, no basta con mirar el error del frontend. Necesitas saber entrada del usuario, modelo elegido, llamadas a herramientas, tiempo de respuesta, consumo de tokens, tipo de error y salida final.

Resumen

vercel/ai no es un modelo nuevo, ni solo un componente de chat.

Se parece más a infraestructura para desarrollar aplicaciones de IA con TypeScript: Providers unificados, salida en streaming, tool calling, gestión de estado frontend y escenarios de Agent dentro de un SDK open source.

Para equipos que ya usan Next.js, React, TypeScript y Node.js, puede reducir mucho el costo de ingeniería entre “la API del modelo funciona” y “la experiencia de producto es usable”.

Pero no es una capa universal. La elección de modelos, permisos, control de costos, logs, monitoreo y seguridad de negocio siguen siendo responsabilidad del desarrollador.

Si quieres crear aplicaciones de IA, no entrenar modelos, Vercel AI SDK es un toolkit que vale la pena probar temprano.

Referencias

SSRF de alta gravedad en Next.js CVE-2026-44578: alcance e indicaciones de actualización

Sun, 17 May 2026 17:27:13 +0800

Next.js divulgó en mayo de 2026 una vulnerabilidad SSRF de alta gravedad: CVE-2026-44578.

Según el aviso de seguridad de GitHub / Vercel GHSA-c4j6-fc7j-m34r y el registro de NVD, el problema afecta a aplicaciones Next.js autoalojadas que usan el servidor Node.js integrado y están expuestas a solicitudes WebSocket upgrade maliciosas. Un atacante podría hacer que el servidor proxifique solicitudes hacia destinos internos o externos arbitrarios, exponiendo servicios internos o endpoints de metadata en la nube.

Los despliegues alojados en Vercel no están afectados. Las versiones corregidas son 15.5.16 y 16.2.5.

Resumen rápido

Si ejecutas Next.js en tus propios servidores, contenedores, Kubernetes, ECS, VPS, bare metal o PaaS autogestionado, revisa esto primero.

Rangos afectados:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Casos no afectados o de menor riesgo:

Aplicaciones desplegadas en Vercel.
Aplicaciones actualizadas a 15.5.16, 16.2.5 o versiones posteriores.
Escenarios donde no se expone el servidor Node.js integrado.
Entornos donde el proxy inverso o balanceador ya bloquea WebSocket upgrades innecesarios y el tráfico saliente está restringido.

Orden recomendado de respuesta:

Confirmar la versión de next que realmente corre en producción.
Actualizar las aplicaciones autoalojadas a una versión corregida cuanto antes.
Si no puedes actualizar de inmediato, bloquear WebSocket upgrades innecesarios en el proxy inverso o balanceador.
Restringir el acceso de los servidores de aplicación a metadata cloud, paneles internos y servicios internos sensibles.
Revisar solicitudes WebSocket upgrade recientes y logs de acceso interno.

Qué es la vulnerabilidad

CVE-2026-44578 es una vulnerabilidad Server-Side Request Forgery, o SSRF.

El riesgo central de SSRF es que el atacante no accede directamente a sistemas internos, sino que induce a tu servidor a enviar solicitudes en su nombre. Los servidores suelen estar más cerca de redes privadas, plataformas cloud y servicios internos, por lo que si se convierten en proxy pueden alcanzar recursos que el atacante no podría tocar desde fuera.

En este caso de Next.js, el problema está en la ruta de manejo de WebSocket upgrade. El aviso indica que aplicaciones autoalojadas que usan el servidor Node.js integrado pueden ser forzadas, mediante solicitudes WebSocket upgrade construidas especialmente, a proxificar solicitudes hacia destinos internos o externos arbitrarios.

Los puntos de riesgo incluyen:

Servicios HTTP internos.
Paneles de administración.
Direcciones de metadata cloud.
Servicios internos de contenedores o clústeres.
APIs internas accesibles solo desde el servidor.

La puntuación CVSS v3.1 es 8.6 High, con este vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

Esto significa que el ataque es de red, de baja complejidad, no requiere privilegios ni interacción del usuario, y afecta principalmente a la confidencialidad.

Por qué el autoalojamiento es más peligroso

El aviso afirma explícitamente que los despliegues alojados en Vercel no están afectados.

El foco real son los despliegues autoalojados. La razón es simple: sus entornos de red varían mucho. Algunos exponen directamente el origin server; otros están detrás de Nginx, Traefik, Ingress, Cloudflare, ALB o gateways propios; otros corren en VMs cloud, redes de contenedores o clústeres Kubernetes.

Si esos entornos no restringen el tráfico saliente, el proceso Next.js podría alcanzar:

Direcciones de metadata cloud como 169.254.169.254.
Rangos de IP privados.
Servicios expuestos solo dentro de una VPC.
Redis, Elasticsearch, Prometheus, Grafana y otros componentes internos.
Kubernetes Services, Pods o endpoints de administración.

Por eso el peligro de SSRF no está solo en Next.js, sino en qué puede alcanzar desde la red donde vive.

Cómo saber si estás afectado

Primer paso: revisar la versión de next.

En el directorio del proyecto:

`1`	`npm ls next`

`1`	`pnpm why next`

También puedes inspeccionar:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

Si la versión cae dentro de estos rangos, hay que actuar:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Segundo paso: revisar el modelo de despliegue.

Presta atención a:

Servicios de producción iniciados con next start.
Servidores Node.js personalizados que alojan Next.js.
Imágenes Docker que arrancan directamente un servidor Next.js.
Autoalojamiento en Kubernetes / ECS / VPS / bare metal.
Un origin de Next.js todavía accesible detrás de un proxy inverso.
Redes de aplicación que pueden acceder a servicios internos o metadata cloud.

Si la aplicación está desplegada en Vercel, el aviso oficial indica que no está afectada por esta vulnerabilidad. Aun así, conviene mantener Next.js actualizado, porque versiones cercanas pueden incluir otros parches de seguridad.

A qué versión actualizar

Las versiones corregidas oficiales son:

15.5.16
16.2.5

Ejemplo de actualización:

`1`	`npm install next@15.5.16`

O si usas 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

`1`	`pnpm add next@16.2.5`

Después, reconstruye y publica:

1
2

npm run build
npm run start

O sigue tu flujo CI/CD para reconstruir y publicar la imagen Docker.

Si tu proyecto está fijado en 14.x o 15.x, no conviene saltar apresuradamente a 16.x solo por este parche. Es más seguro actualizar primero a la línea 15.5.16, probar y publicar, y luego planificar una migración de versión mayor.

Mitigaciones temporales

Si no puedes actualizar de inmediato, la idea principal del aviso es: no exponer el origin server directamente a redes no confiables; si WebSocket upgrade no es necesario, bloquearlo en el proxy inverso o balanceador; y restringir en lo posible el tráfico saliente del origin.

Medidas posibles:

No exponer directamente el origin server de Next.js.
Filtrar WebSocket upgrades innecesarios en Nginx, Ingress, ALB, Cloudflare u otros puntos de entrada.
Si el negocio no usa WebSocket, rechazar solicitudes con semántica de upgrade.
Aplicar restricciones de egress para impedir acceso a metadata cloud y rangos internos sensibles.
Usar modos de metadata más seguros ofrecidos por la nube, por ejemplo servicios de metadata que requieren token.
Añadir autenticación y aislamiento de red a paneles administrativos, bases de datos, cachés y sistemas de monitoreo.

Las reglas de proxy inverso son mitigaciones temporales, no sustituyen la actualización. Una vulnerabilidad del framework debe resolverse finalmente con una versión corregida.

Revisión operativa

Como este problema afecta sobre todo a la confidencialidad, la pregunta clave es si el servidor fue usado para alcanzar recursos internos.

Revisa:

Logs web con Upgrade, Connection, Host, rutas o IPs de origen anómalas.
Logs del proxy inverso o balanceador con WebSocket upgrades inusuales.
Conexiones salientes anómalas cerca del servicio Next.js.
Logs de acceso a metadata cloud o uso de credenciales.
Accesos anómalos a servicios internos de administración, monitoreo, caché o búsqueda.
Uso inusual de credenciales temporales IAM, access keys o tokens.
Procesos, descargas o movimientos laterales sospechosos en contenedores o hosts.

Si sospechas explotación:

Conserva logs y evidencia.
Rota credenciales cloud, API keys, contraseñas de bases de datos y session secrets que pudieran haberse expuesto.
Revisa llamadas API recientes en la cuenta cloud.
Comprueba registros de acceso a servicios internos.
Reconstruye contenedores o hosts afectados.
Revisa controles de egress y protección de metadata.

No es lo mismo que el RCE de React/Next.js

Un punto fácil de confundir: CVE-2026-44578 es un SSRF en WebSocket upgrade de Next.js, no el RCE previo relacionado con React Server Components.

Su impacto central es hacer que el servidor solicite direcciones internas o externas elegidas por el atacante. El riesgo principal es exposición de información y exploración de recursos internos.

Los problemas RCE de React Server Components son riesgos de ejecución de código, con consecuencias y rangos de parche distintos.

Por eso no basta con leer “Next.js tiene una vulnerabilidad”. Hay que mapear el CVE concreto con versiones afectadas, modelo de despliegue y versiones corregidas.

Equipos que deben priorizarlo

Prioridad máxima:

Sitios Next.js de producción autoalojados.
Despliegues en VMs cloud, contenedores, Kubernetes o redes internas.
Servidores de aplicación que pueden acceder a servicios de metadata cloud.
Servidores de aplicación que alcanzan paneles internos, bases de datos, cachés o monitoreo.
Origin servers next start expuestos directamente.
Versiones antiguas de next sin proceso claro de actualización.

Prioridad relativamente menor:

Aplicaciones desplegadas completamente en Vercel.
Aplicaciones ya actualizadas a versiones corregidas.
Origins no expuestos directamente, con la capa de entrada bloqueando WebSocket upgrades innecesarios.
Control estricto de salida que impide alcanzar recursos internos sensibles.

Pero “menor prioridad” no significa que no haya que actualizar. Next.js es un componente muy expuesto, y mantener versiones antiguas del framework acumula riesgo.

Checklist para equipos de desarrollo

Puedes seguir esta lista:

Confirmar la versión de next en todos los repositorios.
Identificar todos los despliegues autoalojados, no solo los proyectos en Vercel.
Marcar servicios que usan next start o el servidor Node.js integrado.
Actualizar a 15.5.16, 16.2.5 o posterior.
Reconstruir y publicar imágenes de producción.
Bloquear WebSocket upgrades innecesarios en la capa de entrada.
Restringir acceso de servidores de aplicación a metadata cloud y rangos internos sensibles.
Revisar solicitudes upgrade anómalas recientes y acceso saliente.
Rotar credenciales que pudieran haberse expuesto.
Incluir actualizaciones de seguridad de Next.js en el proceso de actualización de dependencias.

Resumen

CVE-2026-44578 es una vulnerabilidad SSRF de alta gravedad en Next.js que merece atención rápida.

No afecta a despliegues alojados en Vercel, pero sí cubre muchas aplicaciones Next.js autoalojadas: desde 13.4.13 hasta antes de 15.5.16, y desde 16.0.0 hasta antes de 16.2.5. El punto de activación está en el manejo de WebSocket upgrade. Un atacante puede hacer que el servidor proxifique solicitudes hacia direcciones internas o externas, exponiendo servicios internos o endpoints de metadata cloud.

La corrección directa es actualizar a 15.5.16 o 16.2.5. Las mitigaciones temporales son no exponer directamente el origin server, bloquear WebSocket upgrades innecesarios y restringir el tráfico saliente del servidor de aplicación.

Para equipos de operaciones, lo importante no es solo la puntuación CVE, sino qué puede alcanzar tu servidor Next.js desde su posición en la red. En SSRF, el impacto real suele depender de los recursos internos y permisos cloud detrás del servidor.

Referencias: