Los structured outputs en Amazon Bedrock ya están disponibles para todos los modelos Claude de Anthropic, tanto en el endpoint bedrock-runtime, el que se usa con Boto3, como en bedrock-mantle, que expone la Messages API, siempre que el modelo esté disponible en ese endpoint. La promesa es sencilla: el modelo devuelve JSON válido que cumple el esquema que defines, con tipos forzados y campos obligatorios siempre presentes. Para quien lleva meses escribiendo parsers defensivos y bucles de reintento, es una limpieza de código considerable.
Qué son los structured outputs en Amazon Bedrock y por qué importan
Hasta ahora, pedirle a un LLM que respondiera en JSON era un acto de fe con red de seguridad. Se incluía el formato en el prompt, se rezaba para que el modelo no añadiera una frase de cortesía antes de la llave de apertura y, cuando fallaba, se reintentaba la llamada. Cada fallo costaba latencia, tokens y código de mantenimiento. Con esta novedad, AWS traslada esa responsabilidad al propio proceso de generación: la respuesta ya no es texto que luego hay que validar, sino una salida que respeta el esquema desde el principio.
Según AWS, el resultado es doble. Por un lado, desaparece el parseo personalizado, la lógica de reintentos y el postprocesado. Por otro, la salida se limita a los campos definidos en el esquema, lo que reduce el número de tokens generados y puede abaratar las cargas de alto volumen. No es una mejora de capacidad del modelo, sino de fiabilidad del contrato entre el modelo y el resto de tu sistema, y en producción eso suele pesar más que unos puntos en un benchmark.
La disponibilidad cubre todos los modelos Claude en Bedrock, con la salvedad de que el modelo concreto debe estar disponible en el endpoint que uses. Conviene comprobarlo antes de planificar una migración, porque bedrock-runtime y bedrock-mantle no tienen por qué ofrecer exactamente el mismo catálogo en cada momento.
Cómo funcionan los structured outputs en Amazon Bedrock a nivel técnico
AWS indica que la función usa constrained decoding para aplicar el esquema JSON durante la generación de tokens. En lugar de dejar que el modelo elija cualquier token probable y comprobar después si el resultado es válido, el sistema restringe en cada paso los tokens permitidos a aquellos que mantienen la salida conforme al esquema. Es la diferencia entre corregir un examen al final y no dejar que el alumno escriba fuera de las casillas. Por eso las garantías son fuertes: tipos correctos, campos obligatorios presentes y estructura sintácticamente válida.
Hay dos mecanismos disponibles. El primero es el formato de salida JSON Schema, pensado para cuando quieres que la respuesta completa del modelo sea un objeto con una forma concreta, por ejemplo extraer datos de una factura o clasificar un ticket de soporte. El segundo es strict tool use, que fuerza a que los argumentos con los que el modelo invoca una herramienta respeten el esquema de esa herramienta. Este segundo caso es clave en agentes, donde un argumento mal tipado puede romper una cadena entera de llamadas.
La compatibilidad operativa es razonable. La función funciona con batch inference y con streaming, y en bedrock-runtime también con cross-Region inference. Es decir, no obliga a renunciar a las formas habituales de desplegar cargas en Bedrock, ya sean procesos nocturnos masivos, interfaces que muestran la respuesta mientras se genera o arquitecturas que reparten tráfico entre regiones.
Un matiz que conviene tener claro: el constrained decoding garantiza la forma, no la verdad. Un campo de tipo numérico siempre será un número, pero nada asegura que sea el número correcto. La validación semántica sigue siendo tuya.
Cómo pueden aplicar esto las empresas hoy
El primer paso es auditar el código que ya tienes alrededor de llamadas a Claude. Si hay funciones que limpian respuestas, expresiones regulares para extraer un bloque JSON o bucles que reintentan hasta que el resultado se parsea, ahí está el ahorro inmediato. Sustituir esa lógica por un esquema declarado reduce código que mantener y elimina una fuente habitual de errores intermitentes, de esos que solo aparecen en producción y a las tres de la mañana.
El segundo paso es medir antes de celebrar. AWS apunta a una posible reducción de costes en cargas de alto volumen porque la salida se limita a los campos del esquema. Es un argumento razonable, pero el ahorro real depende de cuánto texto sobrante generabas antes. Haz una prueba con un lote representativo, compara tokens de salida, tasa de reintentos y latencia, y decide con tus números. Para una PYME con pocas miles de llamadas al mes, el beneficio principal será menos código y menos incidencias, no una factura notablemente menor.
Tercero, empieza por los casos de extracción y clasificación, donde el esquema es estable y el valor es evidente, y deja los agentes con herramientas para una segunda fase usando strict tool use. Y evita dos errores: diseñar esquemas excesivamente rígidos que obliguen al modelo a inventar valores cuando no hay dato, y prescindir de la validación de negocio porque el JSON sea válido. Incluye siempre una opción explícita para casos desconocidos o campos vacíos.
Análisis Blixel
La fiabilidad aburrida es lo que separa un piloto vistoso de un sistema que se puede dejar funcionando sin vigilancia. Durante dos años, buena parte del trabajo de integración con LLM ha consistido en construir andamiaje para compensar que el modelo no siempre respetaba el formato. Que una plataforma como Bedrock lo resuelva a nivel de generación es una mejora práctica, nada espectacular, y precisamente por eso valiosa.
Dicho esto, hay que moderar el entusiasmo. Los structured outputs en Amazon Bedrock no hacen que el modelo razone mejor ni que sus datos sean más ciertos; solo garantizan que la respuesta llegue con el envoltorio correcto. El riesgo está en confundir las dos cosas: un JSON impecable con un importe equivocado es peor que un error visible, porque pasa todos los filtros técnicos y entra en tus sistemas como si fuera bueno. Quien adopte esta función debería mantener validaciones de negocio y revisión por muestreo.
También hay un aspecto de dependencia. Cuanto más ligas tu lógica a esquemas y mecanismos específicos de una plataforma, más cuesta cambiar de proveedor. No es motivo para evitarlo, pero sí para aislar esa capa en tu código. Mi recomendación es clara: si ya usas Claude en Bedrock, migra primero los flujos de extracción y clasificación, mide el efecto en reintentos y tokens, y retira el código de parseo defensivo solo cuando los datos confirmen que sobra. Si aún no lo usas, esta novedad por sí sola no justifica cambiar de plataforma.
¿Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido común. Hablemos.