No hay stack de catálogo para IA regulada
El mercado quiere venderte una stack. Elige un proveedor, adopta sus modelos, despliega en su región y estarás operando agentes para final de trimestre. Para muchas empresas, esa es una respuesta perfectamente buena.
Solo que, en una empresa regulada, es una trampa, y la razón no es comercial. Qué modelos puedes usar, y dónde pueden ejecutarse físicamente, lo decide tu régimen regulatorio y tu propia homologación de seguridad, no un valor por defecto de un proveedor. Una stack de catálogo trae codificada la respuesta de otro a una pregunta que solo tu función de cumplimiento puede contestar. Por eso nunca pasa la revisión.
Un banco sujeto a DORA y a obligaciones de residencia de datos necesita un despliegue fundamentalmente distinto al de un hospital, y ambos necesitan algo distinto de la arquitectura de referencia de un proveedor. La stack no es un producto que se compra. Es un conjunto de decisiones que tienes que asumir.
El lock-in es un riesgo de concentración, no solo comercial
Estandarizar en un único proveedor de modelos parece una simplificación prudente. En un contexto regulado crea en silencio un riesgo que a tu supervisor le importa activamente.
La capa de modelos es la parte que más rápido se mueve de toda la stack. Ata tu arquitectura a un proveedor y tu arquitectura envejece al ritmo de ese proveedor, hereda sus caídas y depende de que ese proveedor siga dispuesto a servirte en condiciones aceptables. En un negocio no regulado es una molestia comercial. Bajo un régimen de resiliencia operativa, depender de un único tercero insustituible es un riesgo de concentración, y demostrar que no estás expuesto a uno es casi una obligación.
Así que el agnosticismo respecto al proveedor no es un extra que añades para ganar poder de negociación. Es evidencia que tu función de cumplimiento tiene que poder producir: así es como rodeamos a cualquier proveedor concreto, y este es el camino probado que seguiríamos si uno quedara inutilizable mañana.
El gateway de modelos hace intercambiables a los proveedores
La respuesta al lock-in es una única interfaz interna que todos los agentes llaman, detrás de la cual los modelos son intercambiables. Anthropic, Mistral o un modelo open source corriendo en tus propias GPUs están todos tras la misma puerta. El agente no sabe ni le importa cuál respondió.
Tres propiedades separan un gateway real de uno decorativo.
Un fallback documentado y probado. Si un proveedor no está disponible o falla una comprobación de política, el gateway enruta automáticamente a una alternativa. Una portabilidad que no se ha probado antes de depender de ella es un eslogan, no un control. Bajo un régimen de resiliencia operativa, un fallback automático y probado es casi un requisito.
Al menos tres opciones portables documentadas antes de entrar en producción. No después. El momento de demostrar que puedes moverte es mientras todavía tienes la opción de no hacerlo. Tres opciones documentadas y sustituibles antes de depender de ninguna es lo que convierte "podríamos cambiar" en "ya hemos cambiado, aquí está el runbook".
Enrutado por sensibilidad, no por comodidad. El gateway decide dónde puede correr una carga según los datos que transporta, no según qué proveedor es hoy más barato o más rápido. Esa decisión pertenece a la siguiente sección, porque es la que los reguladores escrutan con más fuerza.
La topología de despliegue es una decisión de soberanía de datos, enrutada por clase
Esta es la parte que la mayoría de las arquitecturas de referencia hace mal: eligen una topología de despliegue para todo. Así se acaba o sobrerrestringiendo trabajo barato y no sensible o, mucho peor, dejando que datos regulados lleguen a un sitio al que nunca debieron ir.
La topología no es una decisión. Es una regla de enrutado. Los datos se clasifican por sensibilidad, y la clasificación decide la topología.
| Restricción que afrontas | Topología | Qué ganas | Qué aceptas |
|---|---|---|---|
| Cargas no sensibles, cloud permitida | Cloud (cuenta propia) | Elasticidad, mínima carga operativa | Los datos salen de tu cuenta hacia la región del modelo, si se permite |
| Datos regulados, cloud permitida con reglas de residencia | VPC, fijado a la región | Los datos se quedan en tu perímetro y tu región | Tú operas la frontera y el enrutado |
| Las normas vetan el procesamiento externo | On-premises | Control físico total | La planificación de capacidad y la operación de GPUs son tuyas |
| Sensibilidad máxima, aislamiento obligatorio | Air-gapped | Ninguna vía de salida | Actualizaciones de modelo y operación son manuales y deliberadas |
La regla está por encima de la tabla: clasifica los datos, y la tabla te dice dónde puede correr esa clase. Un mismo proceso de negocio puede contener pasos sensibles y no sensibles, así que el enrutado ocurre paso a paso, no una vez para todo el sistema.
La postura que hace esto defendible es el enrutado por soberanía que falla cerrado. Los datos regulados y personales se quedan dentro de tu perímetro por defecto. Solo las cargas explícitamente no sensibles pueden alcanzar un modelo en región externa, y solo si lo has permitido. Cuando una clasificación es incierta, el sistema trata los datos como sensibles y los retiene. El valor por defecto te protege, y relajarlo exige una decisión deliberada y registrada. "Tus datos nunca salen de casa" deja entonces de ser una frase de marketing. Es una arquitectura en la que la salida se deniega por defecto y se permite solo por política.
Ser dueño de la stack es ser dueño de la salida
Agnóstico respecto al proveedor y despliegue en cualquier sitio solo se sostienen si puedes demostrarlos bajo presión, lo que significa que la salida tiene que ser real, no retórica.
Dos cosas impiden que una plataforma heredada se convierta en silencio en el lock-in que intentabas evitar. Las dos van en el contrato, por escrito.
Escrow y una salida probada. Código fuente y pesos en escrow, y un plan de salida documentado y probado. Una ruta de migración que nunca has ensayado es un deseo, no una garantía.
El activo es tuyo. El runtime gobernado y los agentes son tuyos para operarlos. Tu hoja de ruta sigue avanzando cuando el socio de implementación se marcha. Un socio serio se somete a ser un tercero sustituible bajo las reglas de tus reguladores, porque es exactamente lo que esas reglas exigen de tus proveedores críticos.
La cuestión no es que tengas que construir tú solo cada capa. Reconstruir un gateway de modelos, un motor de políticas y una malla de despliegue desde cero es alrededor de un año de fontanería dura, la mayor parte en los detalles de seguridad y cumplimiento que un regulador inspecciona. La cuestión es que, quien quiera que lo construya, las decisiones siguen siendo tuyas: qué modelos, corriendo dónde, movidos cómo. Son decisiones de cumplimiento vestidas de ingeniería.
Así que la pregunta no es "¿qué stack deberíamos adoptar?". Es si nuestro proveedor principal de modelos quedara inutilizable mañana, por una razón comercial, regulatoria o de caída, cuál es el camino probado al siguiente, y está documentado antes de entrar en producción. Si no puedes responder a eso por modelo y por clase de datos, todavía no tienes una decisión de despliegue. Tienes una esperanza de despliegue.
Si quieres mapear tus clases de datos a las topologías permitidas sobre un proceso real, reserva una reunión.