El problema que Rayfin resuelve — y por qué ahora
El patrón se repite en cada organización que lleva agentes de IA de piloto a producción: el modelo funciona, el caso de uso tiene ROI demostrado, y el proyecto se atasca durante meses construyendo la infraestructura de soporte. Base de datos para persistir el estado de los expedientes. API para que el agente interactúe con los sistemas de negocio. Autenticación con el directorio corporativo. Políticas de acceso que el departamento de seguridad apruebe. Trazabilidad de cada decisión del agente para el auditor. En entidades financieras o aseguradoras bajo DORA o ENS, ese trabajo de backend no es opcional ni acortable.
El resultado más frecuente no es un fracaso técnico. Es un piloto que "funciona bien en el laboratorio" y que nunca consigue los permisos para tocar datos reales de producción porque el marco de gobernanza no está listo. El agente espera. El coste de oportunidad crece. El proyecto pierde momentum.
Rayfin es la respuesta de Microsoft a ese gap. Un SDK open-source y una CLI que permiten al desarrollador —o al agente de código— definir el backend completo en TypeScript y desplegarlo sobre Microsoft Fabric con un único comando: rayfin deploy. Lo que aprovisiona ese comando no es un contenedor genérico. Es un backend enterprise ya integrado con el ecosistema de gobernanza del tenant Fabric del cliente.
El cambio conceptual: hasta ahora, la gobernanza se añadía sobre el backend una vez construido, en forma de capas adicionales. Rayfin invierte el orden: el backend nace dentro del entorno gobernado de Fabric, heredando automáticamente sus controles de seguridad, sus políticas de compliance y sus reglas de acceso. El CISO recibe un sistema ya conforme, no un sistema que hay que conformar.
Qué aprovisiona rayfin deploy
La definición del backend se escribe en TypeScript usando el SDK de Rayfin: modelos de datos, lógica de negocio, endpoints de API, políticas de acceso. Esa definición es declarativa —describe el estado deseado, no la secuencia de pasos para construirlo— y es el artefacto que el equipo versiona en Git como cualquier otro código.
Al ejecutar rayfin deploy sobre esa definición, Fabric aprovisiona automáticamente:
El SDK está disponible en GitHub como proyecto open-source. La CLI es un paquete npm: sin herramientas propietarias, sin vendor lock-in en el tooling de desarrollo. La integración con Replit permite que los propios agentes de código —no solo los desarrolladores humanos— puedan definir y desplegar backends Rayfin como parte de sus flujos de trabajo autónomos.
OneLake como única fuente de verdad — sin silos de datos de agente
El problema más silencioso de los proyectos de IA agéntica en empresas grandes no es el modelo ni el backend. Son los silos. Cada agente que se despliega de forma independiente crea su propia base de datos, su propio esquema, su propia copia de los datos de negocio. A los seis meses, el equipo de datos tiene cinco fuentes distintas que dicen cosas distintas sobre el mismo expediente, el mismo cliente o el mismo contrato.
Rayfin resuelve este problema por diseño. Los datos de aplicación no van a una base de datos externa: van a OneLake, el lago de datos unificado de Microsoft Fabric. Desde OneLake, esos datos son inmediatamente accesibles para el stack analítico completo de Fabric —Lakehouse, Data Warehouse, Real-Time Intelligence, Power BI— sin ningún proceso de sincronización. El agente escribe un registro de decisión en su backend Rayfin y ese registro ya está disponible para el equipo de analítica, para el auditor y para el modelo de reporting regulatorio, sin mover datos ni construir pipelines adicionales.
En sectores regulados, esta propiedad tiene un valor que va más allá de la eficiencia operativa. La segregación de datos entre sistemas operacionales y analíticos ha sido históricamente una fuente de inconsistencias difíciles de justificar ante el regulador. Cuando el agente y el sistema de reporting leen el mismo dato en OneLake, esa inconsistencia desaparece por construcción.
el backend completo
datos con analítica
heredada en el primer deploy
Lo que cambia para sectores regulados
En banca y seguros, el ciclo habitual de un proyecto de backend para agentes de IA tiene una secuencia reconocible. El equipo técnico construye el sistema. El equipo de seguridad revisa el sistema. El CISO pide cambios. El equipo legal pide trazabilidad adicional. El DPO plantea dudas sobre la residencia de los datos. El comité de riesgos aprueba con condiciones. El equipo técnico implementa las condiciones. Cuatro meses después del primer deploy en laboratorio, el sistema llega a producción con parches de compliance añadidos sobre una arquitectura que no los contemplaba desde el origen.
Rayfin no elimina ese proceso. Lo que hace es mover el punto de partida. Cuando el backend se define sobre el tenant Fabric de la organización, el sistema nace ya dentro del perímetro de gobernanza corporativo. Microsoft Entra ID ya está configurado en ese tenant. Las políticas de seguridad del tenant ya están activas. La residencia de datos en OneLake ya está en la región que la organización tiene contratada y auditada. El CISO no recibe un sistema externo que hay que integrar con los controles corporativos: recibe un sistema que ya corre dentro de ellos.
Esto no convierte a Rayfin en una solución llave en mano para el cumplimiento regulatorio —las políticas de acceso específicas, los requisitos de trazabilidad propios de cada regulador y la definición de los datos que el agente puede manejar siguen siendo responsabilidad del equipo de diseño— pero sí elimina una categoría completa de trabajo: el trabajo de integrar el backend con los controles de seguridad corporativos que la organización ya tiene en Fabric.
Para entidades bajo DORA: la capacidad de demostrar que los datos de los agentes residen y se gestionan dentro del perímetro del tenant Fabric —con la misma trazabilidad y las mismas políticas que el resto del patrimonio de datos— simplifica directamente la documentación de dependencias tecnológicas críticas que exige el artículo 28 del reglamento. No lo automatiza. Lo simplifica porque el perímetro de control ya está definido.
Cuándo usar Rayfin — y cuándo no
Rayfin es la herramienta correcta cuando la organización ya tiene Microsoft Fabric como plataforma de datos y está construyendo aplicaciones cuyo backend necesita estar integrado con ese ecosistema de datos. El caso paradigmático es un agente de IA que necesita leer datos de Semantic Models existentes, escribir registros de decisión que el equipo de analítica pueda consumir, y que el comité de riesgos pueda auditar con las mismas herramientas que usa para el resto del patrimonio de datos corporativo.
Rayfin no es la herramienta correcta en cuatro escenarios que conviene tener claros antes de diseñar. Primero, si el tenant Fabric de la organización no existe o no está maduro: Rayfin hereda la gobernanza de Fabric, pero si esa gobernanza no está bien definida, el backend hereda el caos, no el orden. Segundo, para cargas OLTP de alta concurrencia: el modelo de datos de OneLake está optimizado para analítica, no para transacciones de alta frecuencia. Tercero, para arquitecturas event-driven complejas donde el broker de mensajes es el componente central: Rayfin provisiona un backend orientado a APIs, no un sistema de streaming. Cuarto, para proyectos donde el backend necesita correr on-premise sin conectividad a Fabric: Rayfin es una solución cloud-first.
La secuencia de implementación que minimiza el riesgo
La experiencia en proyectos de IA agéntica en sectores regulados sugiere una secuencia de cuatro pasos que maximiza la velocidad sin sacrificar el rigor de gobernanza.
-
Auditar el estado del tenant Fabric antes de empezar Rayfin hereda la gobernanza del tenant. Si las políticas de acceso del tenant no están bien definidas, el backend Rayfin hereda esa indefinición. Antes de escribir una línea de SDK, el equipo debe verificar que el tenant tiene configurado Entra ID con los grupos correctos, que las políticas de datos de OneLake están activas, y que el modelo de Semantic Models que el agente va a consumir está publicado y gobernado. Este trabajo previo no lo hace Rayfin —lo hace el equipo de plataforma— pero su ausencia bloquea cualquier proyecto Rayfin en producción.
-
Definir el esquema de datos y las políticas de acceso en el SDK antes del primer deploy El SDK de Rayfin en TypeScript es la única fuente de verdad del backend. Las políticas de acceso —qué rol puede leer qué datos, qué operaciones requieren aprobación humana, qué campos son sensibles— se definen en ese código y se versionan en Git. Definir estas políticas antes del primer deploy, no como un paso posterior de "hardening", es lo que permite presentar el sistema al CISO con documentación completa desde el día 1.
-
Desplegar en entorno de validación con datos sintéticos El comando
rayfin deployaprovisiona el backend en el tenant Fabric. El primer deploy debe hacerse en un entorno de desarrollo o QA con datos sintéticos que repliquen la estructura de los datos reales sin exposición de información sensible. Esto permite al equipo de seguridad revisar la configuración del backend —endpoints, políticas de acceso, flujo de autenticación— antes de habilitar el acceso a datos de producción. -
Validar la trazabilidad antes de presentar al comité de riesgos En sectores regulados, el comité de riesgos no aprueba el agente: aprueba el sistema completo, incluyendo el backend. La documentación que hay que preparar para esa aprobación incluye el esquema de datos con clasificación de sensibilidad, el mapa de flujos de datos hacia y desde OneLake, las políticas de acceso con los roles Entra ID correspondientes, y el mecanismo de auditoría de decisiones del agente. Rayfin genera parte de esta documentación automáticamente —la arquitectura del backend es el código TypeScript del SDK— pero la clasificación de datos y el análisis de impacto regulatorio son trabajo del equipo de cumplimiento, no del SDK.
Rayfin y el ecosistema de agentes: la pieza que faltaba
Microsoft Build 2026 presentó Rayfin en el mismo contexto que Fabric IQ —la capacidad de los agentes de IA de interactuar directamente con el ecosistema de datos de Fabric— y que la integración con Replit para el desarrollo agéntico. La lectura correcta de ese contexto no es que Rayfin sea una herramienta de productividad para desarrolladores. Es que Microsoft está construyendo un runtime para aplicaciones generadas por agentes.
El escenario que esto habilita en el horizonte de 12 a 18 meses es relevante para los equipos de arquitectura en sectores regulados: un agente de código puede tomar una especificación de negocio, generar el SDK Rayfin correspondiente, desplegarlo sobre el tenant Fabric de la organización y entregar un backend enterprise funcional sin intervención humana en la construcción técnica. La intervención humana se desplaza —del código al diseño del esquema, de la configuración de infraestructura a la definición de políticas de acceso, de la integración técnica a la validación regulatoria.
Este desplazamiento no reduce el rol del arquitecto. Lo reenfoca. En un entorno donde el código de backend puede generarse automáticamente, el valor diferencial está en saber qué restricciones regulatorias deben codificarse en las políticas del SDK antes del primer deploy, qué datos no pueden ir a OneLake aunque técnicamente sea posible, y qué decisiones del agente requieren un human-in-the-loop por requisito regulatorio, no por preferencia de diseño. Ese conocimiento de dominio no lo genera el SDK.
El prerequisito real: la madurez del tenant Fabric
La promesa de Rayfin —backend enterprise en un comando— es real, pero condicionada. El comando despliega un backend que hereda la gobernanza del tenant Fabric. Si el tenant tiene una gobernanza madura —Management Groups bien estructurados, Entra ID con grupos de seguridad correctamente definidos, políticas de datos de OneLake activas, Semantic Models publicados y gobernados— el backend que entrega Rayfin llega a producción listo para el auditor. Si el tenant tiene deuda técnica de gobernanza acumulada, Rayfin la hereda también.
En los proyectos donde hemos acompañado la adopción de Fabric en banca y sector público, el trabajo previo de maduración del tenant suele representar entre el 30% y el 40% del esfuerzo total del proyecto. Ese porcentaje no desaparece con Rayfin. Lo que desaparece es el trabajo de construir el backend sobre esa base. La ecuación correcta no es "Rayfin elimina la complejidad del backend". Es "Rayfin elimina la complejidad del backend una vez que el tenant está listo".
Para equipos que ya tienen Microsoft Fabric desplegado con gobernanza madura —el caso más común en grandes entidades financieras que llevan 18 o más meses con Fabric en producción— Rayfin es inmediatamente accionable. Para equipos que están empezando con Fabric, el proyecto correcto es primero madurar el tenant y después usar Rayfin como acelerador para los backends de agentes.