{"schema_version":"1.0","service":"Publicasta","type":"article","id":964,"slug":"decisions_api_narrow_ai_routing_workflows","title":"La API Decisions de OpenAI apunta a las pequeñas decisiones que ralentizan los flujos de trabajo de IA","excerpt":"La nueva API Decisions de OpenAI está pensada para clasificar, enrutar, puntuar y escalar rápidamente, no para generar contenido abierto. Su bajo precio de entrada resulta atractivo, pero el despliegue fiable exige umbrales, revisiones, caché y un control estricto de las acciones que puede activar.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=es","image":{"url":"https://publicasta.com/storage/projects/8/pages/964/2026/10/a98d089e-7151-40b0-946f-5ff74235001a.webp","alt":"Fotografía editorial de tecnología con un flujo abstracto de enrutamiento de decisiones de IA en un monitor."},"publisher":{"id":8,"slug":"ai_practice","name":"AI Practice","url":"https://publicasta.com/ai_practice"},"author":{"name":"Anton R"},"published_at":"2026-10-25T10:07:11+00:00","updated_at":"2026-10-25T10:07:11+00:00","content_markdown":"La nueva API Decisions de OpenAI está dirigida a una parte del software de IA que rara vez aparece en las demostraciones de lanzamiento: la pequeña decisión que se toma entre dos pasos más grandes.\n\n ![Fotografía editorial de tecnología con un flujo abstracto de enrutamiento de decisiones de IA en un monitor.](https://publicasta.com/storage/projects/8/pages/964/2026/10/a98d089e-7151-40b0-946f-5ff74235001a.webp)\n\n ¿Esta solicitud de soporte debe ir a facturación o al soporte técnico? ¿Un documento está lo bastante completo como para pasar al siguiente flujo de trabajo? ¿Parece seguro ejecutar automáticamente un comando de shell generado? ¿El asistente de voz debe pedir una aclaración, transferir la conversación o continuar?\n\n Estas decisiones son fáciles de describir y costosas de ejecutar mal. Si una aplicación toma una en cada mensaje, documento, transacción o resultado de una herramienta que recibe, la latencia se acumula. También se acumula el coste de enviar cada pregunta a través de un modelo de propósito general. Además, una clasificación incorrecta puede enviar el trabajo a la cola equivocada, exponer información al operador incorrecto o activar una acción que debería haber esperado una revisión.\n\n OpenAI puso la API Decisions a disposición general el 22 de octubre de 2026. Funciona con GPT-6 Luna y devuelve respuestas tipadas en lugar de un párrafo: una probabilidad, una opción de un conjunto predefinido o una puntuación basada en una rúbrica ordenada. OpenAI afirma que el endpoint está diseñado para responder a estas preguntas acotadas hasta 10 veces más rápido que GPT-6 Luna a través de la API Responses. La empresa indica un precio de 0,10 dólares por millón de tokens de entrada, sin cobro por tokens de salida en el endpoint.\n\n Esa combinación hace que Decisions resulte interesante para los equipos que ya están creando productos de IA. Es menos interesante como sustituto de un asistente general. La pregunta útil no es si el modelo puede razonar, sino si un equipo puede definir una decisión lo bastante limitada como para medirla, establecerle un umbral sensato y mantener la acción resultante dentro de un flujo de trabajo controlado.\n\n ## Qué devuelve realmente la API\n\n El endpoint acepta evidencias compartidas y una o más preguntas. Las evidencias pueden ser texto, una conversación ordenada con llamadas a herramientas y sus resultados, imágenes o JSON estructurado. Cada pregunta tiene un tipo, un nombre, instrucciones y, cuando corresponde, un conjunto de opciones permitidas o niveles de puntuación ordenados.\n\n Un `predicate` estima si una condición es verdadera y devuelve una probabilidad entre cero y uno. Esto encaja con preguntas como «¿Este ticket describe un cargo duplicado respaldado por el registro del pedido?» o «¿Esta imagen muestra daños visibles?».\n\n Un `choice` selecciona un valor de un conjunto predefinido. Un sistema de enrutamiento podría ofrecer `billing`, `technical_support`, `account_access` y `human_review`. Una aplicación de voz podría elegir `continue`, `clarify`, `transfer` o `end_call`.\n\n Un `score` evalúa una entrada frente a niveles ordenados, como gravedad baja, media y alta. La respuesta incluye las probabilidades de cada nivel y un promedio ponderado por probabilidad. Ese promedio puede quedar entre dos niveles, lo que resulta útil para ordenar, pero es peligroso si un desarrollador lo trata como una medición mágicamente precisa.\n\n El endpoint puede formular hasta 400 preguntas en una sola solicitud, frente al límite de 200 preguntas durante la beta pública. Esto importa cuando muchos atributos independientes pueden evaluarse con las mismas evidencias. No significa que deban agruparse decisiones dependientes. Si la pregunta dos solo debe formularse después de responder la primera, las solicitudes separadas facilitan la inspección y las pruebas del flujo de control.\n\n La salida tipada de la API es su principal diferencia como producto. Se puede instruir a un modelo general para que devuelva JSON, pero el desarrollador aún debe validar esa salida y gestionar valores malformados o ambiguos. Decisions limita el espacio de respuestas a nivel de API. Eso reduce el trabajo de análisis, pero no hace correcto el juicio subyacente.\n\n ## Dónde encaja en una aplicación real\n\n Los casos de uso más sólidos son las decisiones repetitivas con un conjunto de respuestas acotado y un siguiente paso claro. Conviene pensar en el endpoint como una capa rápida de juicio dentro de un programa existente, no como un empleado autónomo.\n\n Un flujo de documentos podría utilizarlo para decidir si un certificado subido contiene los campos requeridos, identificar la categoría del documento y enviar el elemento a la cola adecuada. La extracción del documento puede seguir necesitando un sistema independiente. Decisions responde a la pregunta más concreta de qué debe ocurrir después.\n\n Un sistema de soporte podría clasificar un ticket, estimar su urgencia y determinar si el mensaje del cliente contiene información suficiente para una primera respuesta. Un resultado con baja confianza podría enviarse a una cola humana en lugar de utilizarse para enviar una respuesta automática.\n\n Un sistema de orquestación de agentes podría utilizar una pregunta de opción para seleccionar la siguiente herramienta de un conjunto pequeño y revisado. Por ejemplo, una solicitud entrante podría dirigirse a una herramienta de búsqueda, una consulta de cuenta, una función de programación o un paso de aclaración. El modelo elige entre esas opciones; la aplicación sigue siendo responsable de los permisos, la validación de argumentos, los límites de frecuencia y la ejecución.\n\n Un flujo de trabajo de seguridad u operaciones podría puntuar una acción propuesta antes de ejecutarla. OpenAI cita a Datadog, que utiliza el endpoint para evaluar comandos de shell generados por agentes antes de una remediación autónoma. Es un patrón potencialmente útil, pero no debe interpretarse como un límite de seguridad completo. Una puntuación basada en un modelo puede añadir una señal para revisión. No puede sustituir las listas de comandos permitidos, el aislamiento en un entorno controlado, las comprobaciones de identidad, las restricciones del sistema de archivos ni una política de aprobación.\n\n Las aplicaciones de voz son otro caso natural, porque una decisión lenta resulta perceptible para quien habla. Decisions ahora ofrece integración nativa con GPT-Live y puede activarse cuando llegan transcripciones de entrada o de salida. Una aplicación podría decidir si el asistente debe pedir una aclaración, transferir una llamada o actualizar el estado de una interacción. OpenAI afirma que Speak redujo en las pruebas el tiempo hasta su siguiente acción de 1,4 segundos a 0,13 segundos con su integración. Es un resultado comunicado por el proveedor, no una garantía para cualquier sistema de voz, pero ilustra por qué un endpoint especializado puede importar más en un bucle interactivo que en un proceso por lotes.\n\n ## La arquitectura práctica: modelo, umbral, acción\n\n Una implementación fiable necesita tres capas separadas.\n\n La primera capa es la pregunta. Debe describir evidencias observables y distinguir respuestas cercanas. «¿Esto es bueno?» no es una pregunta apta para producción. «¿El mensaje contiene una solicitud para cancelar una suscripción de pago, en lugar de una solicitud de información sobre precios?» se acerca mucho más a una pregunta útil.\n\n La segunda capa es la política que interpreta la respuesta. Una probabilidad de 0,82 no significa que la aplicación deba actuar. El equipo tiene que decidir si 0,82 basta para una ruta automática, si 0,55 debe activar una revisión y si determinadas categorías requieren siempre la intervención de una persona, independientemente del nivel de confianza.\n\n La tercera capa es la acción. El modelo no debería recibir una autoridad amplia simplemente porque ha devuelto una opción válida. La aplicación debe asignar un valor permitido a una función conocida y rechazar cualquier valor que quede fuera de esa correspondencia. Las operaciones sensibles deben exigir una autorización independiente y, cuando corresponda, una confirmación humana.\n\n Esta separación también permite evaluar el sistema. Los equipos pueden cambiar un umbral sin reescribir el prompt. Pueden comparar las decisiones del modelo con ejemplos etiquetados. Pueden medir falsos positivos y falsos negativos según el coste de cada error. Un filtro de fraude, un enrutador de soporte y una cola de moderación de contenido no deberían usar el mismo umbral solo porque utilizan la misma API.\n\n La guía para desarrolladores de OpenAI señala algo parecido: hay que usar ejemplos etiquetados de la aplicación para establecer los umbrales. El consejo puede pasar inadvertido porque el endpoint devuelve probabilidades y valores de confianza que parecen cuantitativos. Esos números solo sirven para ordenar y enrutar cuando se han calibrado con los datos propios de la organización.\n\n ## El diseño de prompts es ahora diseño de políticas\n\n Una decisión limitada sigue dependiendo en gran medida de las evidencias y las instrucciones que se le proporcionan. El prompt debe definir qué cuenta como evidencia de respaldo, qué hacer cuando falta información y cómo distinguir un caso límite de uno claro.\n\n Supongamos que un equipo quiere enrutar facturas. Una pregunta débil podría pedir al modelo que «elija el departamento adecuado». Una pregunta preparada para producción especificaría los departamentos disponibles, los campos que identifican cada uno, el significado de un documento incompleto y la regla aplicable cuando hay señales contradictorias. También podría incluir una opción explícita de `human_review` en lugar de obligar al modelo a elegir una cola de negocio cuando la entrada sea ambigua.\n\n Los ejemplos deben cubrir los casos normales y los casos de fallo. Incluye mensajes breves y extensos, varios idiomas si el producto los acepta, registros contradictorios, campos ausentes, JSON mal formado e intentos de inyectar instrucciones en la evidencia. La evidencia son datos. No debe permitirse que reescriba la política de decisión.\n\n Para las decisiones basadas en imágenes, define qué puede ver realmente el modelo y qué no puede determinar. Una foto puede mostrar una abolladura, pero no demostrar la causa del daño. Una captura de pantalla puede mostrar un mensaje de error, pero no probar que la cuenta esté comprometida. El espacio de respuestas debe reflejar esa distinción.\n\n Cuando varias preguntas comparten el mismo documento fuente o conversación, coloca el material reutilizable en la entrada compartida y modifica las instrucciones de la pregunta. La API admite el almacenamiento en caché de prompts para este patrón. La documentación indica que el prefijo reutilizable debe contener al menos 1.024 tokens y que la entrada almacenada en caché tiene un precio reducido. La caché puede disminuir el coste y la latencia, pero también exige que los desarrolladores entiendan sus límites y eviten incluir en un prefijo material específico del solicitante o sensible que pudiera reutilizarse en el contexto equivocado.\n\n ## El coste es bajo, pero el volumen cambia el cálculo\n\n El precio publicado de Decisions es de 0,10 $ por cada millón de tokens de entrada sin caché, mientras que la entrada almacenada en caché cuesta 0,01 $ por millón de tokens. El endpoint no cobra por los tokens de salida. A primera vista, esto hace que muchas tareas de enrutamiento parezcan casi gratuitas.\n\n La factura real depende de cuánta evidencia se envíe con cada pregunta. Un documento de políticas, el historial de una conversación o la salida de una herramienta que se repiten pueden ser mucho más extensos que la propia instrucción. Enviar el mismo contexto grande por separado para cada decisión anula la ventaja de contar con un clasificador pequeño. La caché ayuda cuando el prefijo es estable, pero las escrituras en caché y el procesamiento regional pueden añadir costes.\n\n Los equipos deberían medir el coste por tarea empresarial completada, no por llamada a la API. Si un clasificador rechaza un elemento y lo envía a una cola manual, la llamada al modelo puede ser barata mientras el proceso completo se vuelve más lento. Si una ruta automática genera una acción incorrecta aguas abajo, el coste de corregirla puede superar con creces la factura de tokens.\n\n El endpoint puede plantear muchas preguntas independientes en una sola solicitud. Eso puede reducir la sobrecarga de las peticiones, pero no debería convertirse en una excusa para preguntar todo lo imaginable sobre cada elemento. Las preguntas adicionales aumentan la complejidad, dificultan la evaluación y pueden animar a los equipos a actuar basándose en puntuaciones que nadie ha validado.\n\n Un piloto sensato registra al menos el recuento de tokens de entrada, la tasa de aciertos de caché, los percentiles de latencia, la distribución de respuestas, la tasa de revisión, la tasa de correcciones y el tiempo de finalización posterior. En productos interactivos, la latencia p95 importa más que la media. En las colas administrativas, pueden ser más importantes el rendimiento y la carga de trabajo de los revisores.\n\n ## Privacidad y controles regionales\n\n La API admite la residencia de inferencia en Estados Unidos y Europa, y OpenAI afirma que la retención cero de datos está disponible para clientes que cumplen los requisitos. La documentación para desarrolladores también incluye compatibilidad con HIPAA para clientes elegibles y describe la disponibilidad de Private Link. Son controles útiles, pero la organización que implemente el sistema aún debe comprobar los requisitos de elegibilidad, los contratos, la configuración del endpoint y las limitaciones de cada función.\n\n El procesamiento regional no equivale a una estrategia de privacidad completa. El equipo todavía debe decidir si la entrada contiene datos personales, si es necesario enviar el registro completo, durante cuánto tiempo los registros de la aplicación conservan la solicitud y la respuesta, y quién puede consultar los informes de uso. Cuando sea viable, la eliminación de datos identificativos y la minimización deberían hacerse antes de la llamada al modelo.\n\n El JSON estructurado no vuelve segura por sí solo la información sensible. Un registro de cliente enviado como `input_json` sigue siendo un dato del cliente. Las imágenes también son sensibles si contienen rostros, direcciones, información médica o pantallas confidenciales. La pregunta adecuada no es si la API acepta el formato, sino si el flujo de trabajo tiene una razón defendible para transmitir esa información.\n\n La misma cautela se aplica al almacenamiento en caché de prompts. Reutilizar un documento de referencia estable es eficiente. Reutilizar entre solicitudes no relacionadas un prefijo que contiene datos privados de un cliente es un error de diseño. Las claves y los límites de la caché deben formar parte de la revisión del flujo de datos, no ser un añadido de última hora durante la optimización del rendimiento.\n\n ## Qué no sustituye Decisions\n\n El endpoint no es un sistema general de extracción. Si la aplicación necesita un objeto complejo con muchos campos, una explicación escrita o una salida que siga un esquema personalizado, la API de Responses con Structured Outputs puede ser más adecuada. Si el modelo necesita solicitar una herramienta con argumentos, el uso de funciones puede ser una abstracción más clara.\n\n No es un motor de reglas. Cuando una condición puede expresarse de forma exacta, es preferible una regla determinista. Por ejemplo, una cuenta no debería considerarse elegible porque un modelo tiene la certeza de que su saldo está por debajo de un umbral. La aplicación puede comparar el saldo directamente.\n\n Tampoco es, por sí sola, una aprobación de seguridad. Que el modelo elija “seguro” no autoriza una acción irreversible. Cualquier operación que pueda gastar dinero, cambiar permisos de acceso, enviar un mensaje al exterior, modificar datos de producción o ejecutar código debe estar rodeada de permisos, listas de permitidos, entornos aislados, límites de transacción, pasos de aprobación y registros de auditoría.\n\n No sustituye la revisión humana en casos ambiguos o de alto impacto. Una respuesta tipada es más fácil de consumir que un texto libre, pero una serialización limpia puede hacer que un juicio incierto parezca más concluyente de lo que es. El sistema debería conservar la confianza, las referencias a la evidencia y el motivo por el que se derivó el caso a revisión.\n\n ## Un piloto pequeño que puede generar evidencia útil\n\n Un equipo que esté considerando el endpoint debería empezar con una decisión recurrente cuyo resultado ya pueda medirse. No conviene comenzar con un flujo cuyo éxito dependa de cinco llamadas al modelo y de varios traspasos mal definidos.\n\n Primero, recopila una muestra de entradas reales y pide a revisores cualificados que etiqueten la acción correcta. Mantén esas etiquetas separadas de los prompts utilizados para las pruebas. Incluye ejemplos difíciles y casos límite, en lugar de seleccionar solo los más evidentes.\n\n Después, define un conjunto finito de respuestas. Añade `human_review` cuando la incertidumbre sea un resultado legítimo. Especifica qué autoriza cada respuesta y qué no autoriza. Si la acción no puede describirse con claridad, probablemente la decisión sea demasiado amplia.\n\n A continuación, prueba tres modos operativos: enrutamiento automático por encima de un umbral alto, revisión dentro de una franja intermedia y una alternativa segura por debajo del umbral inferior. Compara esos resultados con el proceso actual. Un piloto que solo informe de la precisión del modelo, sin medir la carga de los revisores ni los errores posteriores, no responderá a la pregunta de negocio.\n\n Registra la información suficiente para reconstruir una decisión sin almacenar más datos sensibles de los necesarios. Guarda la versión de la pregunta, el modelo, el umbral, la respuesta, la confianza, la acción ejecutada y cualquier corrección posterior. Si cambia un prompt, trata el cambio como una entrega de software y vuelve a ejecutar el conjunto de evaluación.\n\n Por último, ejecuta el endpoint junto al flujo existente antes de permitirle controlar acciones. El modo sombra puede revelar dónde el modelo discrepa de los operadores experimentados, dónde la evidencia está incompleta y dónde una decisión aparentemente sencilla oculta una política de excepciones.\n\n ## Quién debería probarla y quién debería esperar\n\n La API Decisions merece una prueba en equipos que ya tengan un problema concreto de clasificación, enrutamiento, puntuación o escalado; puedan definir los resultados permitidos; y cuenten con suficientes ejemplos etiquetados para evaluar los cambios. Resulta especialmente prometedora cuando el cuello de botella actual es la latencia repetida durante una interacción en vivo o el coste de enviar cada pequeña decisión a un flujo generativo más grande.\n\n También puede encajar en productos que necesiten evaluar varias preguntas independientes sobre el mismo texto, imagen o registro estructurado. La caché de prompts y los controles regionales refuerzan el caso para cargas de trabajo con contexto compartido estable y requisitos de datos claros.\n\n Los equipos deberían esperar si todavía están buscando un caso de uso, no pueden explicar cómo sería una respuesta correcta o planean dejar que el endpoint elija herramientas y acciones arbitrarias. Un precio bajo por token no compensa una política indefinida. Tampoco debería utilizarse una respuesta rápida para ocultar la falta de controles de autorización, revisión o auditoría.\n\n La importancia más amplia del lanzamiento es arquitectónica. Las aplicaciones de IA se están alejando de una única solicitud grande que intenta comprender, decidir y actuar al mismo tiempo. Un sistema más fácil de mantener separa esas tareas: un modelo puede interpretar la evidencia, un endpoint de decisiones acotado puede elegir entre opciones revisadas y el software convencional puede aplicar los permisos y ejecutar el resultado.\n\n Esa división no eliminará los errores del modelo. Sí los hace más fáciles de medir, contener y corregir. Para la mayoría de los equipos, esa es la razón práctica para probar Decisions: no porque todos los flujos necesiten otro endpoint de IA, sino porque algunos necesitan una capa de decisión más pequeña y con una rendición de cuentas más clara.","available_translations":[{"language":"ar","title":"تستهدف واجهة قرارات OpenAI الخيارات الصغيرة التي تُبطئ سير عمل الذكاء الاصطناعي","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=ar","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=ar","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=ar"},{"language":"de","title":"OpenAIs Decisions API zielt auf die kleinen Entscheidungen, die KI-Workflows ausbremsen","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=de","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=de","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=de"},{"language":"en","title":"OpenAI’s Decisions API Targets the Small Choices That Slow Down AI Workflows","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=en","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=en","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=en"},{"language":"es","title":"La API Decisions de OpenAI apunta a las pequeñas decisiones que ralentizan los flujos de trabajo de IA","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=es","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=es","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=es"},{"language":"fr","title":"L’API Decisions d’OpenAI cible les petits choix qui ralentissent les workflows d’IA","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=fr","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=fr","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=fr"},{"language":"pl","title":"Decisions API od OpenAI celuje w drobne wybory spowalniające przepływy pracy AI","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=pl","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=pl","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=pl"},{"language":"ru","title":"API Decisions от OpenAI нацелен на небольшие решения, замедляющие рабочие процессы ИИ","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=ru","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=ru","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=ru"},{"language":"zh","title":"OpenAI 的 Decisions API 瞄准拖慢 AI 工作流的小决策","html_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=zh","markdown_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=zh","json_url":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=zh"}],"_links":{"self":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/decisions_api_narrow_ai_routing_workflows?lang=es","html":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=es","canonical":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows?lang=es","markdown":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.md?lang=es","json":"https://publicasta.com/ai_practice/decisions_api_narrow_ai_routing_workflows.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/ai_practice","channel_articles":"https://publicasta.com/api/public/v1/channels/ai_practice/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}