La femtech entra en la era de la IA con un problema mucho más serio que el hype: la confianza

Hay sectores donde una mala decisión de producto se arregla con una nota de prensa, un parche y algo de paciencia. La salud femenina no es uno de ellos. Si una app de bienestar falla al recomendar una rutina, molesta. Si una plataforma femtech se equivoca al tratar datos sobre menstruación, fertilidad, embarazo o síntomas íntimos, el daño es más profundo: afecta a la privacidad, a la autonomía de la usuaria y, en el peor caso, a decisiones de salud reales.

Eso es lo que hace interesante la intervención de Laure Lydon, vicepresidenta de seguridad de Flo Health, en Infosecurity Europe 2026. No porque descubra de repente que la confianza importa —esa parte ya la sabíamos todos—, sino porque apunta a algo que muchas compañías siguen tratando como detalle de UX: en femtech, la seguridad y la privacidad no van detrás de la IA. Van delante. Si llegan tarde, el producto ya ha perdido.

La frase clave de Lydon no fue tecnológica, sino estratégica: la pregunta no era si podían usar IA, sino cómo hacerlo de forma segura y sin erosionar la confianza de las usuarias. Parece obvio. No lo es. Basta ver cuántas empresas siguen desplegando modelos, asistentes y funciones “inteligentes” antes de cerrar cuestiones básicas de minimización de datos, control de acceso, explicabilidad o gobernanza del proveedor.

Aquí está el quid: la femtech toca una categoría de datos que el derecho europeo trata con pinzas, y con razón. El GDPR coloca los datos de salud en las categorías especiales del artículo 9. Su tratamiento está prohibido salvo excepciones concretas. A eso se suma que el artículo 5 exige minimización, limitación de la finalidad y exactitud; el artículo 25 obliga a aplicar protección de datos desde el diseño y por defecto; y el artículo 32 impone medidas técnicas y organizativas apropiadas. Si encima añades IA generativa, modelos predictivos o asistentes conversacionales, el riesgo deja de ser abstracto.

Lo relevante de esta historia no es solo Flo. Es lo que Flo representa: una clase de empresas que ya no pueden vender confianza con eslóganes mientras construyen IA sobre datos íntimos, inferencias delicadas y cadenas de proveedores opacas. La regulación europea, desde el GDPR hasta el AI Act, ya no deja mucho espacio para la improvisación elegante.

La confianza en femtech no es branding. Es base legal, arquitectura y producto

Conviene empezar por una obviedad incómoda: en salud digital, “confianza” no significa que la usuaria encuentre la interfaz amable, el tono empático o el logo tranquilizador. Significa que entiende qué datos se recogen, para qué, quién accede, cuánto tiempo se conservan, si alimentan modelos, si se comparten con terceros y qué margen real tiene para negarse sin perder el servicio entero.

Eso, traducido al GDPR, implica varias obligaciones concretas. El artículo 13 exige informar de forma clara en el momento de la recogida. El artículo 7 eleva el listón del consentimiento cuando esa sea la base jurídica: debe ser libre, específico, informado e inequívoco, y retirarlo debe ser tan fácil como darlo. El artículo 9.2 añade que, para categorías especiales como datos de salud, el consentimiento explícito suele ser el punto de apoyo más visible en servicios directos al consumidor, salvo que la empresa quiera construir una arquitectura jurídica más sofisticada y muy bien defendible.

La cuestión se complica cuando la app no solo registra datos declarados por la usuaria, sino que infiere información nueva. Un patrón de uso, un retraso en el ciclo, cambios en síntomas o en conductas de sueño puede derivar en probabilidades de embarazo, señales hormonales, estrés o riesgo de patología. No hace falta que el dato original venga etiquetado como “médico” para que la inferencia resultante sea sensible. El Comité Europeo de Protección de Datos ha sido consistente al interpretar ampliamente el concepto de dato de salud cuando la información revela el estado físico o mental de una persona.

Por eso la conversación sobre IA en femtech no puede quedarse en “securizar el modelo”. El problema es previo: qué variables entran, qué inferencias salen, qué usos secundarios se permiten y qué controles frenan la tentación comercial de reciclar datos íntimos para entrenamiento, personalización agresiva o analítica comportamental. Dicho de otro modo, si tu arquitectura de datos parece diseñada por crecimiento y no por prudencia, la IA solo amplifica el defecto.

Flo Health insistió en dos ideas que sí merecen atención: la anticipación del riesgo antes de construir sistemas y el énfasis en la elección de la usuaria. Ninguna es revolucionaria en papel. Pero ambas son las correctas. El artículo 25 del GDPR no pide una política bonita, pide decisiones de diseño. Qué campos son opcionales. Qué identificadores se desacoplan. Qué trazas se desactivan. Qué retención se reduce. Qué datos no salen del dispositivo. Qué proveedor no entra en la cadena. Esa es la diferencia entre privacidad como eslogan y privacidad como ingeniería.

La paradoja de la IA en salud femenina: cuanto más útil puede ser, más peligroso es hacerla mal

La femtech tiene un incentivo obvio para adoptar IA. Un modelo puede detectar patrones en síntomas, ayudar a responder preguntas frecuentes, priorizar señales de riesgo, personalizar contenido, mejorar adherencia y reducir fricción en la experiencia. Bien aplicada, la IA puede servir a millones de usuarias con una escala que ningún equipo clínico o de soporte alcanzaría.

El problema es que la misma capacidad de inferencia que hace útil la tecnología la vuelve regulatoriamente explosiva. Un asistente puede sonar prudente y aun así inducir error. Un clasificador puede no “diagnosticar” formalmente y, sin embargo, influir en decisiones de salud. Un sistema puede prometer anonimato mientras conserva suficientes señales para reidentificar indirectamente a una persona. Y una empresa puede decir que no vende datos mientras permite ecosistemas de terceros que los absorben por telemetría, SDKs o servicios de analítica.

Si suena familiar, lo es. En los últimos años, las apps de salud reproductiva han vivido un escrutinio desproporcionadamente intenso por una razón simple: manejan datos que pueden afectar a derechos fundamentales, reputación, relaciones personales e incluso seguridad física en algunos contextos jurisdiccionales. Eso ha elevado la vara de lo aceptable. Lo que en otra app sería una mala práctica, aquí puede convertirse en una crisis de confianza sistémica.

La propia noción de “modo anónimo”, mencionada por Lydon, ilustra bien el asunto. Es una medida valiosa, pero solo si el anonimato resiste el examen técnico y jurídico. Bajo el GDPR, datos verdaderamente anónimos quedan fuera del reglamento. Pero el estándar es altísimo: si existe una posibilidad razonable de reidentificación mediante medios que puedan utilizarse, ya no hablamos de anonimización sino de seudonimización, y eso sigue siendo dato personal. El considerando 26 del GDPR no deja mucho margen para la fantasía de marketing.

En otras palabras: un “modo anónimo” no es un botón mágico. Hay que mirar identificadores del dispositivo, IP, eventos de uso, patrones temporales, metadatos, copias de seguridad, registros de soporte, integraciones móviles y claves internas de cuenta. Si cualquiera de esas capas permite volver a unir a la persona con el historial, el anonimato era más bien una aspiración estética.

Y aquí entra la ironía habitual del sector: cuanto más presume una empresa de proteger a la usuaria, más alto será el coste reputacional si el diseño no aguanta una auditoría seria. Las promesas de privacidad, cuando son ambiciosas, no se celebran; se verifican.

GDPR: lo que de verdad aprieta a una empresa femtech que despliega IA

Hay cuatro bloques del GDPR que una compañía femtech con ambiciones de IA debería tener clavados, no en la presentación de compliance, sino en el backlog del producto.

1. Base jurídica y datos de categoría especial

El artículo 6 exige una base jurídica para cualquier tratamiento. El artículo 9 añade una capa extra para datos de salud. En servicios directos al consumidor, el consentimiento explícito suele ser la salida más visible, pero es una base frágil si el diseño empuja a aceptar sin alternativa real o mezcla finalidades incompatibles en un mismo gesto. Si además la empresa quiere usar los datos para entrenamiento de modelos, investigación interna, personalización y marketing, tendrá que segmentar finalidades con precisión quirúrgica. Lo de “acepta todo para mejorar tu experiencia” no supera una lectura adulta del reglamento.

2. Protección de datos desde el diseño

El artículo 25 obliga a integrar privacidad desde el diseño y por defecto. En una app de ciclo o fertilidad, eso puede traducirse en decisiones muy concretas: no exigir nombre real, permitir uso local de ciertas funciones, separar identificadores de contenido sensible, desactivar por defecto comparticiones innecesarias, limitar períodos de conservación y evitar SDKs intrusivos. Si la IA necesita enormes volúmenes de datos históricos para rendir, la empresa debe demostrar por qué, durante cuánto tiempo y con qué controles. “Porque el modelo aprende mejor” no zanja la proporcionalidad.

3. Seguridad del tratamiento

El artículo 32 no receta herramientas concretas, pero sí exige medidas apropiadas al riesgo, incluyendo seudonimización, cifrado, capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia, así como procesos de verificación y evaluación periódica. En femtech, esto alcanza tanto a la app y la nube como a pipelines de entrenamiento, entornos de pruebas, registros, proveedores de LLM, sistemas de observabilidad y gestión de secretos. La seguridad de IA no es solo prompt injection y filtrado de salidas. Empieza bastante antes: inventario de datos, segregación, acceso mínimo, logging útil sin exceso de datos sensibles y pruebas de abuso realistas.

4. Evaluación de impacto

El artículo 35 del GDPR exige una evaluación de impacto relativa a la protección de datos, la famosa DPIA, cuando un tratamiento probablemente entrañe un alto riesgo para los derechos y libertades. Combinar datos de salud, perfiles a gran escala y decisiones o recomendaciones asistidas por IA encaja cómodamente en el territorio de alto riesgo. Si la empresa no ha hecho una DPIA seria antes del despliegue, va tarde. Y si la ha hecho como formulario interno de 12 páginas lleno de frases blandas, peor: deja rastro documental de que sabía que había riesgo y aun así no profundizó.

Un detalle que demasiadas compañías siguen subestimando: la DPIA no es una ceremonia previa al lanzamiento. Debe revisarse si cambian las finalidades, las fuentes de datos, la lógica del modelo, los terceros implicados o el contexto de uso. La IA se actualiza. El riesgo también.

Lo que añade el AI Act: menos margen para vender “asistencia” cuando en realidad influyes en salud

La Ley de IA de la UE complica aún más el tablero. No porque prohíba de entrada la IA en femtech, sino porque obliga a clasificar con más rigor qué hace realmente el sistema y en qué categoría regulatoria cae.

El AI Act entró formalmente en vigor el 1 de agosto de 2024, aunque sus obligaciones se aplican de forma escalonada. Las prohibiciones empiezan antes que otros bloques; las reglas para modelos de propósito general y para sistemas de alto riesgo llegan en fases posteriores. Ese calendario importa porque muchas empresas están actuando como si tuvieran tiempo de sobra. No tanto.

En salud digital, la pregunta central es si el sistema de IA puede considerarse de alto riesgo, por ejemplo porque forme parte de un producto regulado o influya en decisiones relacionadas con la salud y la seguridad de las personas. Si una función “solo orienta” pero empuja conductas médicas, clasifica riesgos o prioriza alertas que pueden afectar a la usuaria, no bastará con llamarla bienestar preventivo y confiar en que nadie mire debajo del capó.

Para los sistemas de alto riesgo, el AI Act exige un marco de gestión de riesgos, gobernanza de datos, documentación técnica, trazabilidad, transparencia hacia el usuario, supervisión humana, robustez, ciberseguridad y monitorización poscomercialización. No son adornos. Son piezas operativas. Y aunque una funcionalidad concreta no termine clasificada como alto riesgo, seguirá enfrentándose a obligaciones de transparencia si interactúa con personas o genera contenido sintético en contextos sensibles.

La colisión interesante entre GDPR y AI Act está en la gobernanza del dato. El GDPR pregunta si puedes tratar ese dato y con qué límites. El AI Act pregunta además si los datos son adecuados, pertinentes, suficientemente representativos y gobernados para evitar sesgos o fallos de rendimiento peligrosos. Traducido: no basta con tener permiso. También tienes que demostrar que no estás construyendo una máquina de recomendaciones opacas sobre datos defectuosos.

Para femtech, eso abre una herida poco discutida: los sesgos de entrenamiento. Si un modelo se ha afinado con poblaciones limitadas, autoseleccionadas, de determinados mercados o franjas de edad, la “personalización” puede ocultar errores sistemáticos. Lo delicado no es solo la discriminación clásica. Es el falso aire de precisión en cuestiones corporales altamente variables. Una app que sugiere demasiado, demasiado pronto y con confianza performativa puede hacer más daño que una app humilde.

Cuando la cadena de terceros se convierte en el verdadero riesgo

Muchas compañías tecnológicas siguen describiendo sus servicios como si fueran productos cerrados. No lo son. Son ensamblajes. Una femtech moderna puede depender de nube pública, herramientas de analítica, procesadores de pagos, servicios de mensajería, plataformas de soporte, proveedores de identidad, motores de personalización y uno o varios proveedores de IA, ya sea mediante API o mediante modelos desplegados en infraestructura propia. Cada capa introduce riesgo legal y técnico.

En el GDPR, el artículo 28 regula la relación con encargados del tratamiento. Exige un contrato con materias concretas: objeto, duración, naturaleza, tipo de datos, categorías de interesados, instrucciones documentadas, medidas de seguridad, subencargados, asistencia al responsable y retorno o supresión de datos. En la práctica, el problema no suele ser la ausencia de DPA, sino la superficialidad del análisis previo. La empresa firma, archiva y sigue adelante, como si una plantilla contractual resolviera la exposición.

No la resuelve. Si un proveedor de IA usa prompts o entradas para entrenamiento ulterior, si aloja datos fuera del EEE, si conserva logs más tiempo del necesario, si carece de segregación suficiente entre clientes o si no ofrece controles de retención y borrado, la femtech se mete en una zona de riesgo evidente. Y no vale decir que el tratamiento lo hace “el proveedor”. Frente a la usuaria y frente al regulador, la responsabilidad sigue sentada en casa.

Las transferencias internacionales añaden otra capa. Tras la sentencia Schrems II del Tribunal de Justicia de la UE en julio de 2020, cualquier exportación de datos personales fuera del EEE exige revisar no solo el mecanismo formal, como cláusulas contractuales tipo, sino también si el país de destino permite en la práctica un nivel de protección esencialmente equivalente. El Data Privacy Framework UE-EE.UU. ha dado cierto oxígeno a muchas transferencias a proveedores estadounidenses, pero no elimina el deber de diligencia. Menos aún cuando se trata de datos de salud y servicios con alta sensibilidad social.

Un error frecuente en proyectos de IA es evaluar al proveedor principal y olvidarse de la cadena de subprocesadores. El modelo se sirve a través de una plataforma, que a su vez depende de otra infraestructura, que usa logging de un tercero, que deriva soporte a otra entidad, y así sucesivamente. Cuando estalla un incidente o surge una reclamación de acceso, la supuesta arquitectura “controlada” se parece más a una muñeca rusa con APIs.

Seguridad útil, no seguridad teatral

Lydon habló de operar de forma anticipatoria. Tiene sentido. En IA aplicada a salud íntima, la seguridad defensiva no puede consistir en una mezcla de controles tradicionales y fe en que el equipo de producto ya hará lo correcto. Hace falta seguridad útil: aquella que reduce de verdad la probabilidad de daño para la usuaria.

Eso empieza por una decisión aburrida pero decisiva: limitar el dato antes de protegerlo. Cifrar más información de la que necesitas sigue siendo recoger demasiada información. Después llega la segregación de entornos. El histórico sensible no debería circular alegremente por entornos de desarrollo, notebooks improvisados o pruebas de producto con datos “casi reales”. Los pipelines de machine learning requieren inventario de datasets, control de versiones, aprobaciones de uso, trazabilidad de entrenamiento y políticas de borrado verificables.

Hay además amenazas específicas de IA que en femtech tienen un coste reputacional especialmente alto. La fuga de datos vía prompts o outputs, la extracción de información sensible de conjuntos de entrenamiento, la manipulación de instrucciones, el acceso no autorizado a historiales conversacionales y la sobreexposición de logs son más que cuestiones técnicas. Son detonantes de pérdida de confianza. El daño no se limita al incidente inicial: se propaga a través de prensa, redes, litigios y retirada del consentimiento.

Si la empresa incorpora asistentes conversacionales, el diseño de seguridad debe asumir que las usuarias preguntarán cosas profundamente íntimas y quizá médicamente urgentes. Eso obliga a definir límites de uso, derivaciones a ayuda humana, mensajes de no sustitución clínica y mecanismos para evitar que el sistema improvise con exceso de seguridad. Un chatbot amable y convincente es un riesgo cuando se equivoca con aplomo.

También hay una cuestión de gobernanza interna. ¿Quién puede aprobar nuevas finalidades de uso de datos? ¿Quién revisa prompts de sistema, reglas de retención, cambios de proveedor o nuevas integraciones? Si la respuesta real es “producto decide y legal revisa al final”, el diseño ya viene torcido. En compañías serias, seguridad, privacidad, legal, ingeniería y producto deben compartir un punto de control antes de que la función llegue al mercado. No para bloquear por deporte, sino para evitar el clásico accidente corporativo de alto crecimiento: descubrir tarde que una funcionalidad brillante tiene pies regulatorios de barro.

La lección que deja Flo: el control de la usuaria tiene que ser real, no decorativo

Flo destacó el valor de la elección de la usuaria y del control sobre sus datos. De nuevo, bien. Pero merece precisión. El control real no es un centro de privacidad con veinte toggles crípticos. El control real es que la persona pueda usar el servicio sin verse empujada a compartir más de lo necesario, pueda retirar permisos sin castigo desproporcionado, pueda borrar datos sin obstáculos absurdos y pueda entender si una función de IA usa su historial o no.

En GDPR, el artículo 15 reconoce el derecho de acceso; el 16, rectificación; el 17, supresión; el 18, limitación; el 20, portabilidad; y el 21, oposición en determinadas circunstancias. En femtech con IA, esos derechos no deberían resolverse con flujos manuales y semanas de espera. Si el producto presume de empoderar a la usuaria, el ejercicio de derechos debe ser visible, comprensible y eficiente.

Hay un punto especialmente delicado: el uso de datos para entrenar o afinar modelos. Aunque jurídicamente puedan existir configuraciones distintas según la finalidad y la base legal, desde la perspectiva de confianza la pregunta es brutalmente simple: ¿la usuaria sabe si sus datos íntimos alimentan un sistema que luego se usa para otras personas? Si la respuesta depende de leer tres capas de políticas y un anexo técnico, la transparencia falla aunque el texto sea jurídicamente impecable.

Eso explica por qué el argumento de Lydon sobre “cómo hacerlo sin comprometer la confianza” importa más de lo que parece. En femtech, la confianza no se mantiene solo evitando filtraciones. Se mantiene evitando sorpresas. Una práctica puede ser formalmente defendible y aun así resultar inaceptable para la usuaria cuando la descubre. Y si algo ha enseñado el mercado digital es que la distancia entre legalidad mínima y legitimidad percibida puede ser devastadora.

Lo que deberían estar revisando ahora mismo los equipos de producto, privacidad y seguridad

Si diriges seguridad, producto o compliance en una empresa de salud digital, esta historia deja trabajo concreto. No mañana. Ahora.

Primero, mapa de datos. No uno teórico, sino un inventario vivo: qué datos de salud se recogen, qué inferencias se generan, qué componentes de IA los tocan, qué proveedores participan, dónde residen, cuánto se conservan y qué logs quedan. Si no puedes dibujarlo en una hora sin discutir tres versiones internas, tu gobierno del dato es más optimista que real.

Segundo, revisión de bases jurídicas y finalidades. Muchas apps han ido sumando usos con el tiempo y hoy mezclan servicio principal, investigación interna, personalización, prevención de abandono y mejora algorítmica bajo un consentimiento que nació para algo mucho más simple. Eso pide cirugía regulatoria. Segmentar finalidades suele ser incómodo para el crecimiento. También suele ser lo correcto.

Tercero, DPIA de verdad para funciones de IA. No centrada solo en la seguridad perimetral, sino en daño a derechos y libertades: inferencias inesperadas, decisiones sesgadas, información clínicamente confusa, retención excesiva, transferencias, acceso interno y transparencia insuficiente. Si la funcionalidad afecta a decisiones de salud o puede influir materialmente en ellas, la revisión debe ser especialmente exigente.

Cuarto, contratos y due diligence de terceros. Artículo 28 del GDPR para encargados, revisión de subencargados, localización de datos, retención, entrenamiento con datos del cliente, seguridad, derechos de auditoría y respuesta a incidentes. Los proveedores de IA conversacional merecen un examen mucho más duro que la media. No porque sean malos por definición, sino porque la mayoría fueron diseñados para velocidad, no para intimidad biomédica.

Quinto, controles de producto. Etiquetado claro de funciones basadas en IA, límites de uso, advertencias cuando no sustituyen consejo médico, rutas de escalado a humano, logs minimizados, borrado efectivo y paneles de privacidad que no oculten las decisiones relevantes. Si una usuaria no entiende en dos minutos cómo se usa su dato más sensible, el producto está fallando una prueba básica de confianza.

Sexto, preparación de incidentes. El artículo 33 del GDPR obliga a notificar violaciones de seguridad a la autoridad de control en 72 horas cuando sea probable que entrañen riesgo para los derechos y libertades de las personas. El artículo 34 exige comunicación al interesado cuando exista alto riesgo. En femtech, la evaluación de impacto reputacional y personal de una brecha suele inclinar la balanza hacia la gravedad. Esperar a “entenderlo del todo” puede salir carísimo. La capacidad de contener, clasificar y comunicar es tan crítica como la prevención.

La discusión que viene: no toda femtech es sanidad regulada, pero casi toda toca riesgo regulatorio serio

Una objeción habitual es que muchas apps femtech no son dispositivos médicos ni servicios sanitarios en sentido estricto, sino herramientas de bienestar, seguimiento o educación. Cierto. Y justo ahí vive parte del problema. El mercado ha explotado en una zona híbrida donde la utilidad percibida puede acercarse a la salud aunque el encaje regulatorio del producto sea más ambiguo. Esa ambigüedad comercial no desactiva ni el GDPR ni, potencialmente, el AI Act.

De hecho, el riesgo aumenta cuando la empresa se beneficia del aura de autoridad sanitaria sin asumir la disciplina completa que esa aura exige. Si una app influye en decisiones sensibles, el usuario no distingue siempre entre wellness, advice, triage o predicción probabilística. Ve una interfaz bien diseñada, una respuesta aparentemente experta y una marca que dice cuidarle. Y actúa en consecuencia.

Por eso el lenguaje importa tanto. Decir “informativo” no neutraliza una experiencia que empuja decisiones. Decir “no sustituye a un profesional” al final de una respuesta no compensa una interacción que ha sonado determinante. En esto, producto, legal y comunicación deben dejar de jugar a pasarse la pelota. La expectativa creada por la interfaz también es parte del riesgo.

La intervención de Lydon en Londres deja una lectura madura: la seguridad no es un coste que frena la innovación, sino una condición para que la innovación sobreviva en un terreno especialmente sensible. La idea no es nueva. Lo nuevo es que, con IA, ya no vale con decirla. Hay que demostrarla en arquitectura, contratos, experiencia de usuario y gobernanza.

Perspectiva: la confianza será el verdadero foso competitivo, pero solo para quien pueda probarla

La femtech lleva años creciendo al calor de una demanda real y desatendida. Eso no va a cambiar. Tampoco va a desaparecer el atractivo de la IA para personalizar, automatizar y escalar. Lo que sí está cambiando es el coste del autoengaño corporativo. Durante demasiado tiempo, parte del sector tech pudo permitirse lanzar primero y ordenar después. En salud íntima y reproductiva, y bajo el escrutinio regulatorio europeo, esa secuencia se está cerrando.

Flo Health ha puesto sobre la mesa una posición sensata: la innovación solo tiene sentido si no rompe la confianza. Bienvenida la sensatez. Pero el mercado ya no premia las intenciones; premia las pruebas. Pruebas de minimización de datos. De controles reales sobre terceros. De transparencia que una persona normal pueda entender. De evaluación previa del riesgo. De capacidad para explicar qué hace la IA y qué no hace. De límites cuando el sistema no debería opinar.

Si una empresa femtech hace esto bien, ganará algo más valioso que un ciclo de titulares favorables: reducirá fricción regulatoria, mejorará retención, soportará mejor una due diligence y construirá una marca menos vulnerable al próximo escándalo del sector. Si lo hace mal, la combinación es letal: exposición GDPR, posible impacto del AI Act, crisis reputacional y pérdida de confianza de una base de usuarias que comparte, quizá, la información más personal de su vida.

La lección final es menos glamurosa que el discurso sobre IA agentica y ecosistemas híbridos humano-máquina. Pero mucho más útil. En femtech, la pregunta estratégica no es quién añade antes la próxima función inteligente. Es quién puede mirar a una usuaria, a un regulador y a un auditor sin pestañear y explicar exactamente qué hace con sus datos íntimos, por qué, con qué límites y con qué pruebas.

Lo demás es demo.