Databricks ai_decide Lleva los Datos Gobernados del Análisis a la Acción

Databricks lanzó Databricks ai_decide el 30 de septiembre, incorporando una función SQL en beta que convierte los datos gobernados en probabilidades, decisiones y puntuaciones. El conflicto es inmediato. Las empresas quieren decisiones asistidas por IA a la velocidad de los datos, pero las decisiones operativas exigen más rendición de cuentas que la generación de texto convencional.

La nueva función evalúa registros estructurados o texto frente a una rúbrica proporcionada por el usuario. Puede estimar si un evento requiere atención, elegir entre resultados definidos o puntuar un caso en una escala ordenada. Esos resultados pueden alimentar posteriormente otra consulta SQL, un flujo de trabajo o una aplicación.

Esto hace que el anuncio sea más relevante que otro endpoint de modelo. Databricks está trasladando el juicio basado en modelos al interior del flujo de trabajo de datos, donde los equipos ya controlan tablas, permisos, pipelines y lógica empresarial. Google Cloud ofrece funciones generativas relacionadas en BigQuery, mientras que las API de modelos generales permiten a los desarrolladores construir sistemas similares manualmente. La competencia ahora gira en torno a quién puede hacer operativas las decisiones probabilísticas sin ocultar su incertidumbre.

Databricks ai_decide Convierte Una Llamada SQL en Varias Decisiones

El cambio importante no es que Databricks pueda invocar un modelo desde SQL. Es que una función gobernada puede devolver varias evaluaciones listas para la toma de decisiones sobre el mismo registro.

Según la publicación de lanzamiento de la empresa, Databricks ai_decide está diseñado para tomar decisiones rápidas sobre datos empresariales gobernados. La función forma parte de la familia más amplia de AI Functions específicas para tareas de la compañía.

Su sintaxis tiene tres partes: un estado, una colección de preguntas y ajustes de versión opcionales. El estado contiene la evidencia que se evalúa. Puede ser texto convencional, un objeto codificado en JSON, una matriz JSON o un VARIANT generado por otra AI Function.

Las preguntas se definen una vez para la llamada y se aplican a cada fila de entrada. Cada pregunta incluye instrucciones y un tipo de respuesta. Algunos tipos también requieren criterios que describan los resultados disponibles.

La referencia de la función documenta tres tipos de respuesta:

• noul estima la probabilidad de que una afirmación sea verdadera y devuelve un número entre 0 y 1.

• choice selecciona una etiqueta entre hasta 255 criterios definidos y devuelve probabilidades para cada etiqueta.

• score evalúa la entrada frente a una escala ordenada que contiene entre 2 y 10 criterios.

El inusual término noul identifica una evaluación probabilística de sí o no. En lugar de forzar una respuesta booleana, la función informa de una probabilidad estimada. Esa distinción importa cuando los sistemas posteriores necesitan umbrales en lugar de afirmaciones absolutas.

Una organización de soporte, por ejemplo, podría preguntar si un ticket necesita una escalada inmediata. También podría preguntar qué equipo debería hacerse cargo del caso y cuán urgente parece la situación. Las tres evaluaciones pueden usar el mismo ticket como evidencia.

El resultado es un VARIANT que contiene una respuesta, metadatos y un campo de error. Un VARIANT es un tipo de dato flexible para valores semiestructurados, como JSON anidado. Las llamadas exitosas identifican la versión de la función, mientras que las fallidas pueden devolver una descripción del error.

Para las preguntas de elección, la salida incluye la etiqueta seleccionada, las probabilidades de cada etiqueta posible y un valor de confianza. Las preguntas de puntuación incluyen una puntuación numérica, las descripciones originales de la escala, probabilidades y confianza.

Este diseño proporciona a los analistas más información que una única etiqueta generada. Un flujo de trabajo puede aceptar automáticamente decisiones de alta confianza, dirigir los casos inciertos a personas y registrar la distribución de probabilidades para su revisión posterior.

Databricks también advierte que las respuestas generadas pueden variar entre llamadas. Es fácil pasar por alto esa afirmación, pero define el principal desafío operativo. La sintaxis SQL hace que la función sea accesible y componible. No hace que el juicio subyacente sea determinista.

Las Decisiones de IA Gobernadas Presionan a los Equipos de Datos

Databricks ai_decide presiona a los equipos de datos para que traten el juicio del modelo como lógica de producción, no como una salida experimental copiada de un chatbot.

Muchas decisiones empresariales ya comienzan en un almacén de datos o lakehouse. Los tickets de soporte, listados de productos, documentos de seguros, informes de incidentes, solicitudes y registros de transacciones terminan convirtiéndose en filas procesadas por pipelines.

El SQL tradicional funciona bien cuando la decisión puede expresarse como una regla exacta. Una transacción por encima de una cantidad fija puede entrar en una cola de revisión. Un ticket con un código de error conocido puede enviarse a un equipo específico.

Los casos más difíciles dependen del significado. Un cliente puede describir una interrupción del servicio sin utilizar el vocabulario oficial de incidentes de la empresa. Un listado de producto puede sugerir idoneidad sin coincidir con una taxonomía controlada. Un caso puede cumplir varias prioridades contrapuestas a la vez.

Las organizaciones suelen gestionar estas situaciones mediante colas manuales o servicios externos de modelos. La revisión manual puede ser lenta. Los servicios externos introducen código adicional, movimiento de datos, credenciales, monitorización y trabajo de gobernanza.

Databricks ai_decide comprime ese recorrido. Un equipo puede expresar una rúbrica cualitativa junto a los datos y recibir evaluaciones estructuradas dentro de SQL. Esas evaluaciones pueden participar después en filtros, joins, paneles, pipelines de Lakeflow, Workflows o lógica de aplicaciones.

La visión general de AI Functions describe funciones integradas para el análisis de documentos, la extracción, la clasificación, la preparación para búsquedas y otras transformaciones. Databricks ai_decide añade una capa explícita de decisión después de esos pasos de preparación.

Consideremos un flujo de trabajo de documentos. ai_parse_document puede convertir un documento cargado en contenido estructurado. ai_extract puede identificar campos especificados. Databricks ai_decide puede entonces evaluar el VARIANT resultante frente a una rúbrica empresarial.

Esa secuencia cambia quién puede crear el flujo de trabajo. Un ingeniero de datos ya no necesita encapsular cada decisión en un servicio personalizado. Un analista puede inspeccionar el estado, los criterios, las respuestas, las probabilidades y los errores mediante herramientas de datos conocidas.

También cambia quién asume la responsabilidad. Una vez que una puntuación generada por IA controla el enrutamiento o la priorización, el equipo de datos es responsable de algo más que el rendimiento de las consultas. Debe ayudar a definir tasas de error aceptables, umbrales de escalada, reglas de monitorización y comportamientos de respaldo.

La gobernanza pasa a formar parte del diseño del producto. Databricks afirma que los datos de documentos permanecen dentro de su perímetro de seguridad. La empresa afirma que no almacena los parámetros transmitidos a las llamadas de AI Functions, aunque conserva metadatos de ejecución como la versión de runtime.

El acceso no es automáticamente limitado. La documentación de Databricks indica que los usuarios reciben por defecto permiso EXECUTE en el esquema system.ai cuando está habilitada la vista previa correspondiente. Los administradores deben eliminar ese permiso a nivel de esquema antes de conceder acceso a funciones o grupos seleccionados.

Esos controles de acceso están también en vista previa pública y requieren activación. Se aplican a las funciones específicas para tareas bajo system.ai, pero no regulan la función de uso general ai_query.

Ese límite importa. Una empresa no puede asumir que habilitar un mecanismo de gobernanza cubre todas las rutas hacia un modelo. Los administradores necesitan políticas separadas para las AI Functions específicas para tareas y las llamadas directas a Model Serving.

Por tanto, el lanzamiento genera presión simultánea sobre los responsables de plataforma, los equipos de seguridad y los líderes operativos. Los responsables de plataforma deben hacer fiable la función. Los equipos de seguridad deben configurar el acceso de forma intencionada. Los líderes empresariales deben definir dónde es aceptable la automatización probabilística.

Las Rúbricas Estructuradas Son el Verdadero Mecanismo

El mecanismo central es un cambio de prompts abiertos a rúbricas explícitas con incertidumbre estructurada.

Un prompt de modelo general puede preguntar: “¿Qué deberíamos hacer con este caso?”. La respuesta puede ser elocuente, pero otro sistema debe analizarla. El modelo también podría inventar una categoría, cambiar su formato o explicar una decisión sin producir un campo fiable.

Databricks ai_decide acota la interacción. El desarrollador define preguntas con nombre, instrucciones y criterios permitidos. La función devuelve una estructura de respuesta predecible a la que el SQL posterior puede acceder.

Esa restricción reduce el trabajo de integración. También expone el contrato de decisión a los revisores. Un especialista en cumplimiento puede examinar la definición de escalada. Un gerente de operaciones puede inspeccionar las descripciones de categorías. Un ingeniero de datos puede verificar cómo las probabilidades se convierten en acciones de flujo de trabajo.

El tipo de elección ilustra este enfoque. Supongamos que una organización de soporte define envíos, facturación y soporte técnico como las únicas etiquetas de enrutamiento. La función debe seleccionar entre esos nombres y devolver una probabilidad para cada uno.

La etiqueta seleccionada es útil, pero la distribución puede ser más informativa. Un resultado muy dividido entre facturación y soporte técnico indica ambigüedad. Un flujo de trabajo puede enviar ese caso a una cola general en lugar de fingir que la etiqueta principal es segura.

El tipo de puntuación utiliza criterios ordenados en lugar de un número de formato libre. Un equipo podría definir tres niveles de urgencia, desde una solicitud rutinaria hasta un bloqueo crítico. La puntuación devuelta es un promedio ponderado por probabilidad de los índices de los criterios.

Ese método conserva información sobre evaluaciones contrapuestas. Si el modelo asigna probabilidad entre varios niveles, el resultado puede ser fraccionario. La salida también conserva la leyenda y las probabilidades que sustentan la puntuación.

Varias preguntas pueden compartir un mismo estado. Esto reduce la necesidad de pasar la misma evidencia por prompts separados para categoría, urgencia, escalada y otros juicios. También mantiene juntas las respuestas relacionadas.

Sin embargo, compartir la entrada no garantiza que cada pregunta represente una evaluación independiente. Los equipos deben comprobar si las instrucciones interactúan de formas inesperadas. También deben verificar si combinar preguntas modifica la calidad, la latencia o el coste de su carga de trabajo.

Databricks afirma que el modelo subyacente puede cambiar si otro modelo ofrece mejores resultados en sus benchmarks internos. La documentación actual asocia los posibles modelos con la licencia Apache 2.0 y dirige a los clientes a las condiciones de modelo aplicables.

Una elección de modelo gestionada reduce la configuración. También significa que el comportamiento de la función puede evolucionar bajo una interfaz SQL estable. Los metadatos de versión ayudan a identificar el contrato de la función, pero los equipos siguen necesitando pruebas de regresión basadas en datos representativos.

Ahí es donde el mecanismo adquiere importancia operativa. Un procedimiento almacenado basado en condiciones deterministas puede probarse frente a salidas esperadas exactas. Una función probabilística necesita comprobaciones de distribución, comprobaciones de umbrales y evaluaciones repetidas.

Los equipos deberían mantener conjuntos de evaluación etiquetados para cada rúbrica importante. Esos conjuntos deberían incluir ejemplos comunes, casos límite, evidencia ausente, evidencia contradictoria y entradas que siempre deberían llegar a una persona.

También deberían separar la recomendación de la ejecución. Una función de decisión puede priorizar una cola de soporte con consecuencias limitadas. Esa misma confianza no debería autorizar automáticamente un reembolso, rechazar a un solicitante, suspender una cuenta o iniciar una respuesta de seguridad.

La interfaz SQL facilita la composición. Un buen diseño de sistemas debe mantener deliberadamente difíciles las acciones de consecuencias significativas.

Databricks ai_decide compite con las llamadas a modelos generales y la IA para almacenes de datos

La principal competencia se da entre una función gestionada específica para una tarea y la flexibilidad de construir lógica de decisión en torno a un endpoint de modelo general.

Databricks ya ofrece ai_query, una función de propósito general que invoca un endpoint de Model Serving. Los desarrolladores pueden elegir un modelo compatible, escribir sus propios prompts y controlar los parámetros y los tipos de retorno.

La documentación de ai_query recomienda que los equipos comiencen con una función de IA específica para una tarea cuando esta se ajuste a su objetivo. Sitúa ai_query en los casos que requieren mayor control sobre el modelo, el prompt, los parámetros o la salida.

Esta distinción crea una disyuntiva clara.

Una función específica para una tarea reduce la configuración e impone un contrato estructurado. Databricks gestiona el sistema detrás de la operación y puede mejorar su implementación. Los equipos pueden centrarse en su evidencia, sus preguntas y sus criterios.

Una llamada a un modelo general ofrece flexibilidad. Los desarrolladores pueden utilizar un modelo personalizado, ajustar la configuración de decodificación, definir un esquema distinto, implementar endpoints de respaldo o conservar una versión fija del modelo. También asumen más trabajo de ingeniería y evaluación.

Databricks ai_decide es más potente cuando una decisión encaja en sus tres formatos disponibles. Probabilidad, elección con nombre y puntuación ordenada cubren muchas tareas de enrutamiento y priorización. No cubren todas las estructuras de decisión.

Una empresa puede necesitar clasificación multietiqueta, estimaciones numéricas con restricciones, citas de la evidencia, exclusiones basadas en reglas o una cadena de preguntas dependientes. Los desarrolladores pueden seguir necesitando ai_query, funciones personalizadas o una aplicación externa para esos casos.

El panorama competitivo también se extiende más allá de Databricks. Google Cloud documenta una función AI.GENERATE_BOOL para BigQuery que devuelve un resultado booleano, detalles de la respuesta e información de estado. Puede procesar texto y contenido no estructurado referenciado mediante Gemini.

La función booleana de Google admite parámetros de modelo y de solicitud. Su documentación también advierte que el diseño de prompts afecta a los resultados y que la planificación de consultas puede hacer que la inferencia del modelo procese más filas de las previstas.

Google ofrece por separado AI.IF, que su documentación describe como compatible con la optimización de prompts y un modo optimizado. Ese modo puede entrenar un modelo destilado para reducir el coste y la latencia a escala.

Databricks adopta un enfoque más amplio, orientado a rúbricas, en una sola llamada. Databricks ai_decide puede responder varias preguntas y devolver probabilidades para elecciones con nombre o puntuaciones ordenadas. La función booleana documentada de Google se centra en la generación de verdadero o falso, aunque BigQuery ofrece funciones escalares y generativas adicionales.

Ninguno de los dos enfoques elimina el diseño de aplicaciones. La IA nativa de los almacenes de datos reduce la distancia entre los datos y la inferencia, pero los equipos todavía deben elegir umbrales, materializar entradas, controlar permisos y evaluar resultados.

Por tanto, la competencia dependerá de la evidencia operativa, no solo de la sintaxis. Los compradores necesitan saber cómo se comportan las funciones con sus registros, en sus regiones, bajo sus requisitos de cumplimiento y a volumen de producción.

Una función que ahorra trabajo de integración pero crea costes impredecibles tendrá dificultades. También las tendrá un endpoint flexible que exija un equipo especializado para cada tarea rutinaria de clasificación.

Databricks apuesta por que muchas decisiones empresariales comparten suficiente estructura como para merecer una primitiva gestionada. El resultado depende de que esas primitivas sigan siendo comprensibles cuando las organizaciones las conecten a acciones reales.

Las decisiones rápidas aún necesitan una validación lenta

La etiqueta beta es la advertencia más clara: Databricks ha simplificado la implementación, pero no ha eliminado la incertidumbre, los límites regionales ni la responsabilidad humana.

Databricks ai_decide está disponible como función beta. Los administradores del espacio de trabajo controlan el acceso mediante la página Previews, y la función solo está disponible en regiones compatibles.

No funciona en Databricks SQL Classic. La documentación exige Databricks Runtime 15.4 LTS o posterior y recomienda Runtime 18.2 o posterior para las funciones y el rendimiento actuales.

Estos requisitos previos limitan la adopción inmediata. Las organizaciones con runtimes más antiguos, almacenes Classic, regiones no compatibles o políticas estrictas para funciones en vista previa deben modificar su infraestructura o esperar.

La capa de modelo introduce otra incertidumbre. Databricks afirma que podría cambiar el modelo subyacente cuando sus benchmarks internos identifiquen una opción mejor. Esa evolución gestionada puede mejorar los resultados, pero también crea deriva del modelo desde la perspectiva del cliente.

Una canalización de decisiones no puede depender únicamente de que el nombre de la función permanezca estable. Los equipos necesitan evaluaciones de referencia, controles de versiones, umbrales monitorizados y la capacidad de comparar resultados después de cambios en la plataforma.

La propia rúbrica también puede fallar. Las instrucciones pueden omitir una excepción significativa. Las categorías pueden solaparse. Una escala ordenada puede sugerir una precisión que la evidencia no respalda.

La confianza exige una interpretación cuidadosa. Un campo de confianza alto indica en qué medida el estado respalda la evaluación según el proceso de la función. No establece que la respuesta sea factualmente correcta o justa.

Las salidas de probabilidad conllevan un riesgo similar. Un valor de 0,9 parece preciso, pero los usuarios no deberían asumir que el 90 por ciento de las predicciones comparables serán correctas sin evidencia de calibración. La calibración debe probarse con los propios casos etiquetados de la organización.

La calidad de los datos sigue siendo decisiva. Si el estado contiene registros obsoletos, incompletos o engañosos, una rúbrica bien estructurada aún puede producir una decisión deficiente. Los controles de gobernanza determinan quién puede usar los datos; no garantizan que cada entrada sea adecuada.

El sesgo también puede entrar mediante ejemplos y criterios. La descripción de una categoría puede codificar la práctica histórica de un equipo, incluidos sus puntos ciegos. Una puntuación puede reproducir juicios humanos inconsistentes procedentes de un conjunto de evaluación.

Los usos de alto impacto necesitan salvaguardas más estrictas. Las decisiones de empleo, crédito, salud, seguros, ámbito legal y seguridad implican obligaciones que van más allá de la salida de un modelo. Las organizaciones deberían involucrar a los equipos de dominio, legal, seguridad y riesgos antes de automatizar acciones.

Incluso los flujos de trabajo de menor riesgo necesitan gestión de fallos. La función puede devolver una respuesta nula y un mensaje de error. Las canalizaciones deben decidir si reintentar, pausar, usar lógica determinista de respaldo o derivar el caso a una persona.

Las respuestas generadas pueden variar entre llamadas, según la documentación. Por ello, evaluaciones repetidas pueden producir etiquetas o puntuaciones distintas para registros limítrofes. Los equipos necesitan políticas de idempotencia cuando las acciones posteriores solo deben ocurrir una vez.

El coste merece un escrutinio similar. Cada evaluación respaldada por un modelo consume recursos de inferencia. Ejecutar varias preguntas sobre cada fila de una tabla grande puede convertir una consulta conveniente en una operación costosa.

Los desarrolladores deberían aislar las filas relevantes antes de invocar la función. Deberían materializar conjuntos de entrada estables, impedir la reevaluación accidental de toda la tabla y almacenar las salidas cuando la inferencia repetida no aporte valor.

Ninguna de estas preocupaciones invalida la dirección del producto. Explican por qué las decisiones de IA gobernadas necesitan un estándar diferente al de los resúmenes generados. Un resumen deficiente incomoda a un lector. Una decisión deficiente de enrutamiento o priorización cambia lo que sucede después.

Tres señales mostrarán si la apuesta funciona

La siguiente prueba es si Databricks puede convertir una prometedora abstracción de SQL en una capacidad de producción medible y gobernable.

La primera señal es el rendimiento de evaluación documentado. Databricks no ha presentado benchmarks independientes que establezcan precisión, calibración, latencia o coste en tareas de decisión representativas. Los clientes necesitan evidencia específica para cada carga de trabajo, no una promesa general de velocidad.

Una validación útil compararía Databricks ai_decide con ai_query, reglas deterministas y revisión humana establecida. Debería medir la precisión de las etiquetas, la calibración de probabilidades, la estabilidad entre llamadas repetidas, el tiempo de procesamiento y el número de casos que requieren escalado.

Si los equipos pueden publicar mejoras repetibles con tasas de error controladas, el enfoque específico para tareas ganará credibilidad. Si deben envolver cada llamada en una amplia lógica correctiva, la abstracción ahorra menos trabajo de lo que sugiere la sintaxis.

La segunda señal es una disponibilidad de producción más amplia. La función actualmente lleva una etiqueta beta, requiere habilitar la vista previa, excluye los almacenes SQL Classic y solo es compatible con determinadas regiones.

El avance hacia una disponibilidad más amplia indicaría que Databricks confía en la fiabilidad del servicio, la cobertura de gobernanza y el soporte operativo. Las restricciones persistentes de vista previa limitarían la función a experimentos y flujos de trabajo de bajo riesgo.

La madurez de la gobernanza pertenece a la misma señal. Los administradores necesitan controles claros para permisos de ejecución, acceso a modelos, registros de auditoría, procesamiento regional y cambios en los modelos subyacentes. Estos controles deben funcionar de forma coherente entre plataformas cloud y configuraciones de espacios de trabajo.

La tercera señal es el uso por parte de clientes más allá de las demostraciones. La categorización de productos y el enrutamiento de tickets de soporte son ejemplos comprensibles. La evidencia más sólida procederá de flujos de trabajo de producción con umbrales de revisión publicados y resultados empresariales medibles.

Observe los casos en que las probabilidades cambian el flujo de trabajo, en lugar de limitarse a adornar un panel. Una empresa podría automatizar decisiones claras, enviar registros ambiguos a especialistas y utilizar las correcciones resultantes para probar su rúbrica.

Observe también a los competidores. Google Cloud ya ofrece funciones generativas nativas de almacenes de datos, y otras plataformas de datos siguen añadiendo acceso a modelos cerca de datos gobernados. Una función competidora con una calibración más clara, mayor compatibilidad de entradas o menor carga operativa debilitaría la ventaja de Databricks.

Databricks ai_decide refleja un cambio importante. Las empresas ya no se conforman con modelos que solo describen información. Quieren sistemas que ayuden a elegir, clasificar, enrutar y escalar, sin salir de los controles de datos establecidos.

El siguiente paso prudente no es conectar la función directamente a una acción con consecuencias. Seleccione una cola acotada, defina una rúbrica explícita y cree un conjunto de evaluación etiquetado. Compare las salidas de la función con las decisiones actuales y, después, elija umbrales para la automatización y la revisión humana. Realice un seguimiento por separado de los errores, la incertidumbre, la latencia y la deriva.

¿Qué decisión de su organización es lo bastante repetitiva para evaluarla y, al mismo tiempo, lo bastante reversible para probarla de forma segura? Ese es el punto de partida adecuado para Databricks ai_decide. El valor duradero del producto procederá de una disciplina operativa transparente, no de tratar una salida probabilística como certeza.