Los modelos abiertos de Flo Health se volvieron más seguros y útiles, pero el 47% aún superó ambas pruebas

Los modelos abiertos de Flo Health mejoraron en dos exigentes benchmarks internos, aunque solo el 47% de las respuestas evaluadas cumplió simultáneamente los criterios de seguridad médica y utilidad. La empresa de salud femenina afirma que su sistema de posentrenamiento elevó la seguridad médica del 34% a aproximadamente el 61%. La utilidad aumentó del 42% al 76%.

Estas mejoras procedieron de un proceso basado en preguntas sintéticas, jueces de IA especializados y reglas de evaluación definidas por clínicos. Después, Flo utilizó ajuste fino supervisado y Direct Preference Optimization, o DPO, para incorporar el comportamiento preferido en los pesos de un modelo abierto.

El trabajo importa porque Flo atiende a 81 millones de usuarios activos mensuales, según un caso de estudio de Databricks publicado el 12 de octubre de 2026. A esa escala, incluso una tasa de error baja puede exponer a muchas personas a información de salud incompleta, excesivamente tranquilizadora o confusa.

El resultado también cuestiona el enfoque más simple para la IA generativa orientada a la salud: enviar cada solicitud a un proveedor de modelos frontera y depender de su capa general de seguridad. Flo apuesta por que modelos más pequeños y adaptados pueden ofrecer mayor control y menores costes de inferencia. La cuestión más difícil es si un benchmark diseñado internamente puede demostrar seguridad más allá del entorno que lo creó.

Flo reconstruyó el sistema de evaluación antes de entrenar el modelo

El cambio central no fue un nuevo chatbot ni un modelo fundacional. Flo primero convirtió el juicio clínico en un sistema repetible de evaluación y entrenamiento.

Los equipos médicos, de producto e ingeniería de Flo dividieron la calidad de las respuestas en dos objetivos principales. La seguridad médica constituyó la base, mientras que la utilidad medía si una respuesta proporcionaba ayuda relevante y comprensible a una usuaria.

La distinción parece obvia hasta que un modelo se enfrenta a una pregunta de salud ambigua. Pensemos en alguien que pregunta por qué se le ha retrasado la menstruación. Una respuesta que solo recomiende consultar a un profesional médico podría evitar una afirmación peligrosa, pero ofrece poco contexto inmediato.

La respuesta opuesta también puede fallar. Un modelo podría enumerar estrés, viajes, cambios de peso o ejercicio, pero pasar por alto un embarazo o una condición que requiera evaluación profesional. Esa respuesta parece más útil, pero sus omisiones pueden generar una falsa tranquilidad.

Por ello, Flo trató la seguridad y la utilidad como dimensiones separadas que deben superarse conjuntamente. Su marco final incluyó 26 jueces de IA, es decir, evaluadores automatizados con instrucciones de puntuación y casos de referencia definidos.

Doce jueces aplicaban restricciones de seguridad médica. Seis microjueces examinaban comportamientos más específicos, como fundamentación, encuadre, voz y seguridad detallada. Ocho criterios de utilidad evaluaban exhaustividad, relevancia, coherencia y tono.

La empresa también creó reglas para patrones de fallo recurrentes. Una regla de “causas equilibradas” exigía que las respuestas cubrieran explicaciones benignas y potencialmente graves cuando ambas fueran relevantes. Esto apuntaba a la tendencia de los modelos conversacionales a producir una respuesta tranquilizadora que parece completa.

Flo afirma haber validado estos jueces con casos sintéticos y ejemplos anonimizados de experimentos con usuarios. Cuando un juez automatizado discrepaba de una evaluación humana inicial, revisores clínicos ciegos resolvían el caso.

Algunos casos revisados ayudaron a perfeccionar los jueces. Flo reservó el resto para mediciones posteriores, reduciendo el riesgo de evaluar únicamente con los ejemplos utilizados durante la calibración.

Esta estrategia de evaluación primero es la base de los resultados de benchmark comunicados. También explica por qué el proyecto es más significativo que un ejercicio rutinario de ajuste fino.

Un equipo no puede mejorar de forma fiable la “seguridad” si esa palabra sigue siendo una aspiración amplia. Flo tuvo que expresar esa aspiración como comportamientos individuales y comprobables antes de poder utilizarlos como señales de entrenamiento.

El mismo principio se aplica más allá de la atención sanitaria. Los equipos empresariales suelen poseer amplios conocimientos de dominio, pero estos se distribuyen entre políticas, decisiones de expertos, investigación y excepciones operativas. Los sistemas que respaldan la combinación de conocimientos pueden ayudar a organizar dicho material, aunque la evaluación de modelos sigue requiriendo pruebas específicas para cada tarea y revisores responsables.

El diseño de Flo crea un activo reutilizable. Un modelo fundacional puede quedar obsoleto, cambiar de licencia o perder su ventaja de costes. Las rúbricas clínicas y los casos de evaluación pueden trasladarse al siguiente modelo.

Esa portabilidad establece la tensión principal del artículo. Flo obtiene control al sustituir las supuestas garantías de seguridad de un proveedor general por sus propios estándares. También asume la responsabilidad de demostrar que esos estándares son fiables para una población de usuarias amplia y diversa.

Por qué los modelos abiertos de Flo Health se convirtieron en una apuesta económica

Los modelos abiertos de Flo Health no son solo un proyecto de seguridad. Son un intento de reducir la dependencia de API de modelos costosas y controladas externamente.

Flo utilizaba anteriormente aprendizaje automático tradicional y comenzó a explorar la IA generativa para ofrecer experiencias más flexibles y personalizadas. Un único modelo de propósito general proporcionaba una vía directa hacia esas capacidades, pero introducía tres restricciones.

La primera era el coste de inferencia a escala. Cada respuesta generada puede requerir una solicitud de pago a un proveedor externo. Una diferencia modesta por solicitud adquiere importancia cuando un producto atiende a decenas de millones de usuarios mensuales.

Flo estima que los modelos adaptados y ajustados pueden reducir los costes de inferencia en un orden de magnitud frente a las API de modelos frontera. Esta cifra es una estimación de la empresa, no un análisis divulgado de costes de producción.

La segunda restricción era la dependencia del ciclo de vida del modelo. Un proveedor de API puede retirar un modelo, cambiar su comportamiento, revisar sus reglas de uso o introducir un reemplazo. Cada cambio puede obligar a una aplicación de salud a repetir el trabajo de evaluación.

La tercera era el control limitado sobre el comportamiento de dominio. El ajuste de seguridad de un modelo general debe abarcar muchos temas, culturas, productos y casos de uso. No puede codificar automáticamente cada distinción que los clínicos de Flo consideran importante.

La respuesta de largo plazo de Flo es un sistema de IA compuesto, que combina múltiples modelos y componentes de apoyo en lugar de asignar cada tarea a un único modelo. Ese sistema puede dirigir las tareas simples a modelos más pequeños y reservar los modelos mayores para solicitudes difíciles.

Este camino ejerce presión sobre la estrategia predeterminada de API de modelos frontera. La elección no consiste simplemente en tecnología abierta frente a cerrada. Se trata de seguridad general suministrada por un proveedor de modelos frente a controles específicos del dominio mantenidos por el desarrollador de la aplicación.

Los modelos generales conservan ventajas claras. Sus proveedores pueden invertir intensamente en preentrenamiento, evaluaciones amplias, ejercicios de red team e infraestructura. También pueden actualizar capacidades sin exigir a cada cliente que opere una infraestructura de entrenamiento.

Sin embargo, esas ventajas implican distancia respecto al caso de uso final. Un proveedor no es responsable de la política exacta de respuestas de Flo para síntomas menstruales, preguntas sobre el embarazo u otros temas sensibles de salud femenina.

Flo intenta cerrar esa brecha convirtiendo su experiencia de dominio en infraestructura de evaluación portable. Si cambia el modelo subyacente, la empresa puede volver a ejecutar sus jueces, regenerar pares de preferencias y repetir el posentrenamiento.

Ese proceso desplaza el recurso escaso. El modelo base se vuelve más reemplazable, mientras que el marco de evaluación se vuelve más valioso.

Flo ya ha identificado Gemma, Qwen y Kimi como posibles candidatos futuros de pesos abiertos. Los modelos de pesos abiertos exponen parámetros que los desarrolladores pueden ejecutar y modificar, aunque sus licencias no siempre cumplen todas las definiciones de software de código abierto.

La empresa no ha dicho que una familia de modelos gestionará cada aplicación. Su estrategia, en cambio, trata los modelos como componentes que compiten frente a un conjunto consistente de requisitos médicos y de producto.

Esto vuelve inseparable la afirmación económica de la seguridad. La inferencia de menor coste tiene un valor limitado si un modelo produce peor información sanitaria. Del mismo modo, un modelo más seguro podría seguir siendo poco práctico si atenderlo cuesta demasiado.

El enfoque de Flo busca un modelo que supere ambos umbrales. Las primeras cifras muestran avances, pero no demuestran que el equilibrio esté completo.

Los jueces de IA convirtieron las reglas clínicas en datos de entrenamiento

Flo escaló el juicio experto enseñando a evaluadores automatizados a clasificar respuestas candidatas y luego utilizó esas clasificaciones para cambiar el propio modelo.

El proceso comenzó con más de 15.000 preguntas sintéticas. Flo afirma que derivó las entradas de señales generadas por modelos o agregadas de forma anónima, en lugar de texto libre escrito por usuarios o información identificable.

Esa distinción importa en una aplicación de salud. Entrenar directamente con conversaciones sensibles de usuarios puede introducir exposición de privacidad, cuestiones de consentimiento y riesgos de memorización. Los prompts sintéticos reducen esos riesgos, aunque introducen un problema diferente: si las preguntas generadas reflejan con precisión a los usuarios reales.

Para cada pregunta, el sistema produjo múltiples respuestas candidatas. Los 26 jueces puntuaron después esas respuestas en seguridad, utilidad y criterios de comportamiento más específicos.

Flo seleccionó los resultados más sólidos y los organizó en pares de preferencias. Cada par mostraba al modelo cuál de dos respuestas se ajustaba mejor al comportamiento deseado.

El equipo aplicó primero ajuste fino supervisado, que entrena un modelo para reproducir ejemplos seleccionados. Después utilizó DPO, un método que aumenta la probabilidad de respuestas preferidas en relación con las rechazadas.

El artículo original sobre DPO describe una vía de optimización más simple que el aprendizaje por refuerzo convencional a partir de comentarios humanos. Evita entrenar un modelo de recompensa separado durante la fase de optimización de preferencias.

Flo describe su flujo de trabajo más amplio como ajuste fino por refuerzo. El sistema genera candidatos, los puntúa, selecciona mejores respuestas, entrena el modelo y vuelve a ejecutar la evaluación.

La distinción entre evaluación y entrenamiento es crucial. Un juez de IA no se limita a calificar el modelo final. Su puntuación influye en qué resultados se convierten en ejemplos positivos, por lo que cualquier debilidad del juez puede propagarse al comportamiento entrenado.

Flo se encontró con ese problema en su primer intento. La utilidad mejoró, pero la seguridad médica se mantuvo relativamente estable. Los pares de preferencias no establecían distinciones suficientemente precisas entre los niveles de calidad médica.

Una señal binaria de aprobado o suspenso había descartado información útil. Dos respuestas podrían evitar ambas una declaración explícitamente insegura, mientras que una proporciona un contexto de seguridad mucho mejor.

Flo añadió una puntuación de seguridad graduada después de la puerta binaria. Las respuestas que superaban la prueba básica de seguridad se clasificaban según el grado en que satisfacían plenamente los criterios médicos aplicables.

Ese cambio creó pares de preferencias más precisos. El modelo podía aprender no solo a evitar una respuesta prohibida, sino también a favorecer una respuesta con mejor cobertura y salvaguardas de seguridad.

Este es el resultado técnico más instructivo del proyecto. La optimización de preferencias no puede reparar una señal de recompensa vaga. Si el sistema de evaluación trata la cautela superficial y el encuadre clínico cuidadoso como equivalentes, el modelo no tiene motivo para aprender la diferencia.

Los clínicos siguieron siendo responsables de definir y validar el estándar. No tuvieron que redactar ni etiquetar manualmente cada par de entrenamiento, lo que permitió que su trabajo influyera en más ejemplos.

Sin embargo, la automatización no eliminó el cuello de botella humano. Trasladó el esfuerzo experto hacia etapas anteriores, desde la anotación repetida hasta el diseño de rúbricas, la resolución de casos difíciles y la calibración de evaluadores.

Esa redistribución puede hacer que la adaptación al dominio sea más escalable. También puede ocultar errores tras una puntuación automatizada si los equipos dejan de revisar desacuerdos o casos poco frecuentes.

Por tanto, el método depende de un mantenimiento continuo de los jueces. La orientación médica cambia, el lenguaje de los usuarios evoluciona y las nuevas familias de modelos exponen debilidades distintas. Un conjunto fijo de jueces puede quedar desactualizado aunque haya tenido un buen desempeño durante su validación original.

Databricks AI Runtime hizo que el ciclo fuera repetible

La infraestructura era importante porque Flo necesitaba volver a ejecutar la generación, la puntuación, el entrenamiento y la evaluación como un único ciclo controlado.

Flo entrenó con 32 GPU NVIDIA H100 mediante PyTorch y Fully Sharded Data Parallel. FSDP distribuye los parámetros del modelo, los gradientes y el estado del optimizador entre las GPU para admitir cargas de trabajo de entrenamiento más grandes.

Su stack combinaba Databricks AI Runtime, LLM Foundry, Compose-RL y MLflow. LLM Foundry se encargaba del entrenamiento distribuido, mientras que Compose-RL proporcionaba la capa de optimización de preferencias. MLflow hacía seguimiento de los experimentos y los puntos de control.

La documentación de AI Runtime describe un entorno de GPU sin servidor para cargas de trabajo de aprendizaje profundo. En el proyecto de Flo, esto significaba que los ingenieros podían solicitar cómputo distribuido sin configurar un nuevo clúster para cada experimento.

El beneficio no era simplemente acceder a aceleradores H100. Flo mantenía las operaciones de datos, el seguimiento de experimentos, el entrenamiento de modelos y la evaluación dentro de un mismo entorno.

Esta disposición reduce la fricción entre detectar un fallo y probar una corrección. Un equipo puede ajustar una rúbrica, regenerar preferencias, reentrenar el modelo y comparar el resultado con el punto de control anterior.

El primer resultado de seguridad de Flo muestra por qué importa la velocidad de iteración. El diseño inicial de preferencias mejoró un objetivo y dejó el otro prácticamente sin cambios. El equipo necesitó otro ciclo completo para probar la puntuación graduada de seguridad.

Un stack fragmentado puede hacer que ese ciclo sea más lento y difícil de auditar. Los datos de entrenamiento podrían pasar por sistemas separados, mientras que los puntos de control del modelo, las versiones de puntuación y los informes de evaluación permanecen desconectados.

Un flujo de trabajo unificado puede preservar la relación entre una pregunta, sus respuestas candidatas, las puntuaciones de los jueces, el par de preferencias, la ejecución de entrenamiento y la evaluación final. Esa trazabilidad cobra importancia cuando un modelo produce una respuesta insegura y los investigadores necesitan entender por qué.

El diseño también respalda el plan de Flo de probar modelos abiertos más recientes. Los ingenieros pueden sustituir el modelo base manteniendo gran parte del proceso de generación, puntuación, entrenamiento y seguimiento.

Esa portabilidad es el argumento más sólido para considerar el pipeline como un activo. La capacidad de cómputo se alquila, y los modelos fundacionales cambian rápidamente. Un método validado para convertir estándares de dominio en comportamiento del modelo puede perdurar más.

Aun así, la comodidad de la plataforma no resuelve la cuestión central de la calidad. Los experimentos más rápidos pueden producir más evidencia, pero también una optimización rápida frente a un benchmark incompleto.

El riesgo se parece a enseñar para un examen. Un modelo puede volverse muy bueno para satisfacer las preferencias visibles del evaluador sin llegar a ser igual de seguro ante preguntas inesperadas.

El uso de casos reservados y adjudicación clínica por parte de Flo ayuda a abordar esa preocupación. El estudio de caso público no revela suficiente detalle para determinar cuán amplios eran esos casos o cómo variaba el rendimiento entre grupos de usuarios.

Por tanto, la infraestructura debe entenderse como un acelerador de un proceso de gobernanza. No puede sustituir al proceso de gobernanza en sí.

La puntuación combinada del 47% es progreso, no una prueba

Flo mejoró ambas métricas reportadas, pero la tasa de fallos restante impide que los resultados funcionen como una garantía amplia de seguridad.

El modelo original obtuvo un 34% en el benchmark de seguridad médica de Flo y un 42% en utilidad. Solo el 16% de las respuestas superó ambas dimensiones simultáneamente.

Tras el ajuste fino, la puntuación de seguridad alcanzó aproximadamente el 61%. La utilidad subió al 76%, mientras que la puntuación combinada aumentó al 47%.

El resultado combinado casi se triplicó, pero también significa que el 53% de las respuestas evaluadas no cumplió ambos estándares. Algunas pudieron ser seguras, pero poco útiles. Otras pudieron ser útiles, pero omitir una salvaguarda médica.

Esa distinción afecta las decisiones de despliegue. Un modelo todavía puede respaldar funciones restringidas aunque no cumpla los requisitos para ofrecer consejos de salud sin restricciones. Los controles del producto pueden limitar temas, recuperar información aprobada, solicitar aclaraciones o escalar casos sensibles.

Flo no ha divulgado públicamente el tamaño del benchmark, los intervalos de confianza, los resultados por subgrupos ni la gravedad de los fallos en el estudio de caso. Tampoco identifica el modelo abierto original utilizado para estas puntuaciones reportadas.

Sin esos detalles, los investigadores externos no pueden determinar si un pequeño conjunto de casos recurrentes impulsó gran parte de la mejora. Tampoco pueden comparar directamente el modelo de Flo con las API de frontera o con modelos de salud especializados.

Los 26 jueces se calibraron con participación de clínicos, pero las puntuaciones resultantes siguen siendo mediciones internas. Una replicación independiente daría más peso a las afirmaciones.

La evaluación externa importa porque las preguntas sintéticas pueden diferir de las conversaciones reales. Los usuarios escriben mal los síntomas, omiten contexto, cambian de tema, expresan miedo o hacen preguntas moldeadas por supuestos culturales.

Un benchmark también puede infrarrepresentar afecciones poco frecuentes pero graves. El rendimiento promedio podría mejorar mientras un modelo sigue fallando en los casos con mayor potencial de daño.

La orientación sobre IA en salud de la Organización Mundial de la Salud sitúa la rendición de cuentas, la transparencia y la autonomía humana junto al rendimiento técnico. Estos principios son relevantes incluso cuando una función de IA proporciona información en lugar de diagnóstico.

Flo también debe operar teniendo en cuenta su propio historial de privacidad. En 2021, la Comisión Federal de Comercio de Estados Unidos finalizó una orden que resolvía acusaciones de que Flo compartió información de salud sensible con proveedores de analítica después de prometer mantenerla privada.

El registro del acuerdo de la FTC se refiere a prácticas de datos anteriores, no al nuevo pipeline de entrenamiento. Sigue siendo relevante porque la confianza de los usuarios en una aplicación de salud abarca tanto lo que dice el modelo como la forma en que el sistema maneja la información sensible.

Flo afirma que su proceso de datos sintéticos evitó el texto libre escrito por los usuarios y la información identificable. La empresa también ofrece Anonymous Mode, que, según afirma, puede separar los datos de salud de la identidad de un usuario.

Estas medidas abordan parte del riesgo, pero siguen existiendo varias preguntas. Las señales agregadas aún pueden codificar desequilibrios demográficos. Los datos sintéticos pueden reproducir supuestos del modelo que los generó. Los jueces automatizados pueden recompensar un lenguaje seguro de sí mismo que parece experto.

Por tanto, la expresión “privacy-first” debería describir una dirección de diseño, no una certificación externa completada de este pipeline. Del mismo modo, “safer” es un resultado comparativo de benchmark, no una prueba de que cada respuesta generada sea médicamente segura.

Ninguna de estas limitaciones borra los avances. Aclaran qué respaldan los números.

Flo ha demostrado que su sistema interno puede orientar un modelo abierto hacia un comportamiento definido por clínicos en su conjunto de evaluación. No ha demostrado que el modelo pueda sustituir la atención clínica ni responder de forma segura a todas las preguntas de salud del mundo real.

Tres señales mostrarán si la estrategia se sostiene

La siguiente etapa debe evaluarse mediante replicación entre modelos, supervisión en el mundo real y evaluación independiente, no con otra mejora aislada de benchmark.

La primera señal es si Flo reproduce la mejora en Gemma, Qwen o Kimi. La empresa ha nombrado estas familias de modelos como futuras candidatas para su pipeline.

Mejoras comparables en distintos modelos base respaldarían la afirmación de Flo de que el sistema de evaluación y entrenamiento es el activo duradero. Una gran caída con otro modelo sugeriría que el resultado actual depende en gran medida de un modelo base no divulgado.

La comparación debería conservar el mismo conjunto de evaluación reservado y añadir pruebas diseñadas para las debilidades específicas de cada modelo. De otro modo, los equipos corren el riesgo de seleccionar el modelo que mejor se adapta a una prueba conocida.

La segunda señal es la supervisión en producción. Flo debería informar con qué frecuencia los sistemas desplegados se niegan a responder, escalan casos, recuperan información aprobada o reciben comentarios negativos sobre la calidad.

Las puntuaciones agregadas de benchmark no pueden revelar si los fallos se concentran en el embarazo, la anticoncepción, el dolor, la menopausia o los síntomas urgentes. Los informes a nivel de categoría mostrarían dónde el modelo sigue siendo poco fiable.

La supervisión también debería distinguir entre respuestas de poco valor y respuestas potencialmente dañinas. Una respuesta repetitiva y una respuesta peligrosamente tranquilizadora no deberían tener el mismo peso operativo.

La tercera señal es la validación independiente. Clínicos externos e investigadores de seguridad deberían probar el sistema con casos que el proceso de entrenamiento de Flo no haya generado ni seleccionado.

Los revisores independientes pueden analizar cambios de distribución, variación demográfica, formulaciones adversariales, uso multilingüe y escenarios médicos poco frecuentes. También pueden evaluar si los jueces automatizados favorecen un estilo de comunicación concreto por encima del contenido clínico.

La evidencia de esas tres señales reforzaría el caso de los modelos abiertos de Flo Health. No publicar resultados más amplios dejaría las afirmaciones actuales dependientes de un estudio de caso elaborado por el proveedor y de mediciones diseñadas por la empresa.

Para los desarrolladores, la lección inmediata no es copiar el stack exacto de Flo. Es tratar el diseño de la evaluación como parte del producto, en lugar de como una prueba realizada después del entrenamiento.

Para los compradores empresariales, la pregunta clave también está cambiando. La adquisición de modelos debería examinar quién define el comportamiento aceptable, cómo esas reglas se convierten en pruebas y si el sistema conserva evidencia a lo largo de cada ejecución de entrenamiento.

Los trabajadores del conocimiento y los usuarios de aplicaciones de salud deberían buscar límites más claros. Un producto fiable debería explicar cuándo la salida generativa es informativa, cuándo recupera material revisado y cuándo dirige a alguien hacia atención profesional.

Las mejoras reportadas por Flo hacen que valga la pena seguir su enfoque. El 53% sin resolver hace que el escrutinio sea igualmente necesario.

La próxima actualización decisiva no será una ejecución con más GPU. Será evidencia de que las mismas mejoras de seguridad sobreviven a un nuevo modelo base, preguntas impredecibles de los usuarios y una revisión clínica independiente. Hasta entonces, los lectores deberían considerar el sistema como un prometedor método de posentrenamiento, no como un sustituto verificado del juicio médico.