Caso de Éxito: cómo Omniloy ha conseguido 210.000€ de ENISA (Emprendedoras Digitales)

Cualquier startup que aplique IA a salud, fintech, legaltech o cualquier otro vertical regulado se enfrenta a la misma paradoja cuando solicita un préstamo ENISA: el proyecto es sólido técnicamente, pero difícil de evaluar para quien tiene que decidir si lo aprueba.

‍

Eso no es un detalle menor. Es el factor que más determina el resultado de la solicitud.

‍

En Premoney hemos gestionado más de 400 procesos ENISA con un 89% de aprobación. Y hay un patrón claro: las startups que combinan IA generativa con un sector regulado tienen una tasa de rechazo significativamente más alta que la media. No porque sean peores proyectos. Porque escriben la memoria desde la lógica del founder, no desde la lógica del analista.

En este artículo explicamos como se construye una memoria ENISA que sortea ese problema. Y, al final, un caso real de una empresa en el que lo aplicamos: Omniloy, IA aplicada a hospitales, aprobado por 210.000€ por la línea Emprendedoras Digitales.

Quién evalúa realmente tu memoria ENISA (y por qué eso lo cambia todo)

La mayoría de founders escribe la memoria pensando en un evaluador con su mismo background técnico. Es un error de partida.

El analista que abrirá tu expediente es un profesional con formación en finanzas, contabilidad o gestión empresarial. Lee decenas de memorias al mes, de sectores muy distintos: SaaS hostelería, marketplaces B2C, agritech, ecommerce, healthtech. Su trabajo no es validar la solidez técnica de tu modelo de IA. Su trabajo es responder a una pregunta concreta: ¿esta empresa va a poder devolver el préstamo en los plazos pactados?

Eso significa dos cosas:

1. ‍Tu analista no necesita entender los detalles técnicos. Necesita confiar en que el equipo los entiende. No es lo mismo. La diferencia entre una memoria que entra en detalle de arquitectura LLM y una que demuestra que el equipo sabe manejar esa arquitectura es enorme. La primera abruma. La segunda tranquiliza.
2. ‍Toda la memoria se va a leer en menos de una hora. Tienes ese tiempo para que un profesional sin contexto sectorial salga convencido de que tu proyecto es viable. Si tu narrativa exige que el lector haga el esfuerzo de mapear conceptos, has perdido.

Cuando escribimos una memoria ENISA para un proyecto de IA en un sector regulado, no estamos escribiendo un white paper técnico. Estamos haciendo traducción de viabilidad. Y el público objetivo no es ENISA como institución: es la persona concreta que abrirá tu solicitud un martes por la tarde.

‍

Las tres banderas rojas que un analista detecta al leer "IA + sector regulado"

Cuando un analista identifica que tu proyecto combina IA generativa con un vertical regulado (salud, finanzas, legal, seguros), su radar de riesgo se activa por tres motivos estructurales. Si no los anticipas en la memoria, los detecta él. Y entonces ya estás defendiéndote, no construyendo argumento.

1. Concentración de clientes en early stage

Las startups de IA aplicada a sectores regulados rara vez son negocios B2C o B2B SMB. Vendes a hospitales, a entidades financieras, a despachos profesionales, a aseguradoras. Eso significa pocas cuentas con tickets altos en los primeros años.

Para un analista entrenado en evaluar SaaS de PYME con cientos de clientes pagando 50€/mes, una empresa que factura el 60% de sus ingresos con tres clientes le suena a riesgo de impago. "Si pierden uno, la cuenta de resultados se desploma."

En sectores regulados esto no es un defecto, es la estructura del modelo. Un hospital, un banco o un despacho enterprise firma contratos plurianuales con costes de cambio altísimos. La dependencia inicial está compensada por la rigidez del lock-in.

Si tu memoria no explicita esto, el analista lo lee como concentración. Si lo explicitas con datos sectoriales, lo lee como anclaje contractual.

2. Tecnología frontier sin referente comparable

ENISA evalúa proyectos contra benchmarks. Para un SaaS estándar, los benchmarks son fáciles: KPIs de retención, CAC/LTV, MRR, churn. Para una startup de IA generativa aplicada a un nicho específico, no hay benchmarks públicos. Y un evaluador no puede comparar contra el aire.

Esto produce dos efectos perversos en la memoria:

• El founder, al no tener referencias, tiende a escribir párrafos largos justificando por qué su solución es novedosa.
• El analista, al no poder calibrar, tiende a interpretar la novedad como riesgo no medido.

La solución no es buscar benchmarks que no existen. Es anclar tu proyecto a referencias sectoriales reconocibles que el analista pueda procesar sin esfuerzo, principalmente porque le dan al analista una vara de medir cualitativa.

3. Ciclos de venta largos en proyecciones financieras

Vender a un hospital tarda entre 6 y 18 meses. A una entidad financiera puede tardar 12-24 meses. Un despacho enterprise grande, de 9 a 15 meses.

Eso, en una proyección financiera, dibuja una curva en escalera, no en rampa. Y un analista acostumbrado a SaaS B2C, al ver una curva plana durante los primeros 9 meses seguida de un salto, interpreta una de dos cosas: o el founder es excesivamente conservador (y miente con la proyección), o el modelo de venta no funciona (y va a quemar caja antes de facturar).

Las dos lecturas son malas para tu solicitud.

La memoria tiene que explicar la mecánica del ciclo de venta antes de mostrar la proyección, no después. Si el analista entiende por qué los primeros 9 meses son inversión comercial pura, lee la curva en escalera como rigor. Si no lo entiende, la lee como alarma.

‍

Cómo se construye una memoria que desactiva estas tres alarmas

No hay magia. Hay tres principios estructurales que convierten una memoria de "rechazo en primera vuelta por falta de claridad" en una memoria que pasa el filtro técnico.

Principio 1: Pirámide invertida en la explicación técnica

La mayoría de memorias de IA empiezan explicando la tecnología y terminan explicando el impacto. Hay que hacerlo al revés.

Primero impacto medible. Después caso de uso. Después arquitectura. Si el analista no llega a la arquitectura porque el impacto y el caso de uso ya le han convencido, perfecto: ha leído lo importante. Si llega a la arquitectura, ya está predispuesto a no leerla con desconfianza.

Principio 2: Antinarrativa de cliente concentrado

No defiendas la concentración de clientes minimizándola. Reformúlala como ventaja estructural del modelo. Tres argumentos que funcionan:

• Costes de adquisición compensados por tamaño medio de contrato.
• Costes de cambio que reducen churn estructuralmente bajo benchmarks SaaS.
• Capacidad de generar referencias internas en el sector que aceleran la siguiente venta.

El analista no necesita ver muchos clientes. Necesita entender por qué este número de clientes, en este modelo, es coherente con la fase de la empresa.

Principio 3: Trazabilidad ENISA-hito-resultado

Cada euro solicitado tiene que estar atado a un hito ejecutable, y cada hito tiene que estar atado a un resultado medible. Sin pasos intermedios.

Las memorias que dicen "vamos a usar el préstamo para crecer comercialmente" no convencen. Las memorias que dicen "el préstamo financia 24 meses adicionales de ciclo de venta hospitalaria, lo que permite cerrar 6-8 cuentas adicionales y alcanzar break-even operativo en mes 22" sí. Es la misma realidad. Diferente narrativa.

‍

¿Estás buscando un CFO para tu empresa? Descúbre en que te tienes que fijar, a través de este artículo

‍

Caso real: Omniloy y la línea Emprendedoras Digitales

Omniloy es una startup española de IA generativa aplicada al ámbito hospitalario. Sus productos automatizan tres procesos clínicos: gestión de llamadas y citas (MarIA Recepcionista), transcripción ambiental durante la consulta médica (OmniScribe) y resúmenes inteligentes de historial clínico (SofIA Resúmenes). La compañía fue fundada por Mar Pujadas (CEO) y Enrique Alcázar (CTO), y ha sido seleccionada para programas de referencia en el ecosistema (Wayra, Google for Startups Growth Academy).

La empresa reunía las tres banderas rojas a la vez: cuentas hospitalarias concentradas, IA generativa aplicada a un sector altamente regulado, y ciclos de venta enterprise largos. Sobre el papel, el tipo de expediente que un analista no entrenado en healthtech rechaza por exceso de incertidumbre.

La línea elegida fue Emprendedoras Digitales. Tres motivos por los que tenía sentido por encima de la línea Startups y Pymes:

• Mar Pujadas, cofundadora y CEO, lidera la compañía desde producto hasta comercial. El requisito formal de liderazgo femenino estaba cubierto sin ambigüedad.
• La línea Emprendedoras Digitales se financia con fondos NextGenerationEU. En la práctica, esto se traduce en plazos de resolución más cortos y menos congestión administrativa que la línea general.
• La calidad media de las solicitudes en Emprendedoras Digitales es alta, pero el volumen total es menor que en Startups y Pymes. Mismo rigor técnico, menos cola.

Construímos la memoria en base a tres argumentos centrales:

• Sobre concentración de clientes: explicitamos la estructura de contratos hospitalarios plurianuales con integración técnica profunda y costes de cambio elevados, documentando el churn estructural del segmento.
• Sobre la complejidad técnica: anclamos el proyecto a referencias del ecosistema reconocibles para un evaluador no técnico, y modelamos la diferenciación competitiva en términos de capa de seguridad y compliance clínico, no de arquitectura LLM.
• Sobre el ciclo de venta: modelamos el pipeline comercial por cohortes, con ratios de conversión por fase y tiempo medio en cada fase, vinculándolo explícitamente al calendario de hitos del préstamo a 24 meses.

Resultado: aprobación a la primera, sin requerimiento de información adicional al analista.

"Cuando entras en una solicitud ENISA con un proyecto de IA aplicada a hospitales, necesitas a alguien que sepa exactamente cómo lee un analista. Alberto y su equipo no nos vendieron humo: nos dijeron desde la primera reunión qué partes de nuestro modelo iban a ser cuestionadas y cómo había que argumentarlas. Ha sido una maravilla trabajar con ellos".

— Mar Pujadas, CEO de Omniloy

‍

Tres errores que descalifican una solicitud antes de evaluarse a fondo

Hay tres errores recurrentes que veo en memorias ENISA de startups de IA en sectores regulados. Son letales porque actúan antes de la evaluación cualitativa: hacen que el analista deje de leer con buena fe.

Error 1: Confundir innovación con tecnicismo

Una memoria que dice "implementamos un pipeline RAG con embeddings vectoriales sobre Pinecone usando LLMs propietarios fine-tuneados sobre corpus clínico" no demuestra innovación. Demuestra que el founder no ha pensado en quién va a leer eso. Lo que demuestra innovación es: "el sistema lee la conversación médica en tiempo real y genera el informe clínico estructurado, reduciendo en un 40% el tiempo administrativo del facultativo".

La primera versión te clasifica como riesgo. La segunda te clasifica como solución.

Error 2: Inflar la proyección para parecer ambicioso

Un analista experimentado detecta una proyección inflada en treinta segundos. Cuando ve un MRR proyectado de 200.000€ a 18 meses sin ciclo de venta justificado, no piensa "estos son ambiciosos". Piensa "estos no entienden su mercado, o me están mintiendo". Las dos lecturas descalifican.

‍Es mejor proyectar realista y explicar bien la mecánica del ciclo, que proyectar ambicioso y no poder defenderlo. ENISA evalúa coherencia, no entusiasmo.

Error 3: No anticipar las preguntas obvias

Si tu modelo tiene tres clientes, en algún sitio de la memoria tienes que decir explícitamente por qué tres clientes son suficientes en esta fase. Si tu producto requiere certificación CE clase IIb que aún no tienes, en algún sitio tienes que explicar el plan regulatorio. Si tu equipo no tiene un perfil médico, en algún sitio tienes que justificar cómo se compensa.

Las memorias que dejan estas preguntas sin contestar se devuelven con requerimiento de información adicional. Cada requerimiento añade 7-10 días al proceso.

‍