La mayoría de las empresas no eligió su arquitectura de IA. La fue acumulando. Una licencia de copiloto por aquí, un asistente incrustado por un proveedor por allá, un equipo de ciencia de datos que llama directamente a tres proveedores de modelos, y un puñado de agentes conectados a la mesa de servicio y al CRM por quien fuera más rápido. Dos años de eso dejan a una organización de TI en una posición conocida: valor real en producción y ningún lugar único donde responder la pregunta que tarde o temprano hará un auditor, un director financiero o quien investigue una brecha, que es sencillamente qué habló con qué.
La respuesta que se está imponiendo en 2026 es estructural más que procedimental. En lugar de otro documento de políticas, usted coloca un punto de estrangulamiento en la ruta de red: un gateway de IA centralizado por el que cada llamada al modelo, cada acción de un agente y cada invocación de herramienta se autentica, se autoriza, se registra, se limita por tasa y se atribuye a un centro de costos. Es el mismo movimiento que las empresas hicieron con los API gateways hace una década, y con los proveedores de identidad antes de eso, y funciona por la misma razón. La gobernanza que hay que acordarse de aplicar es gobernanza que se erosiona. La gobernanza que vive en la ruta de datos se aplica sola.
Un gateway de IA es un proxy centralizado que se sitúa entre sus usuarios, aplicaciones y agentes, de un lado, y sus proveedores de modelos, herramientas y fuentes de datos, del otro. Toda solicitud pasa por él, de modo que se convierte en el único lugar donde se verifica la identidad, se aplica la política, se inspeccionan los datos sensibles, se enruta el tráfico al modelo correcto, se registran los prompts y las respuestas, y se atribuye el gasto. En términos de plano de control, el gateway es donde viven las reglas; los proveedores de modelos y los servidores de herramientas son el plano de datos que gobierna.
La urgencia no es teórica. Una investigación publicada por Akamai el 5 de agosto de 2026 encontró que casi la mitad del uso empresarial de IA elude los controles de seguridad corporativos, lo que produce brechas de visibilidad de IA en la sombra a una escala que la mayoría de los equipos de seguridad no ha medido en su propio entorno. En Black Hat USA 2026, en agosto, la seguridad de los agentes de IA dominó la agenda, y los agentes se presentaron como la superficie de ataque empresarial de más rápido crecimiento. Los proveedores se mueven en la misma dirección: Snowflake aprovechó la conferencia para anunciar su Cortex AI Gateway junto con gobernanza de MCP, controles de identidad de agentes y prevención de exfiltración de datos, y Microsoft llevó Project Perception, su plataforma de agentes de ciberseguridad, a vista previa pública a principios de agosto de 2026. Mientras tanto, Gartner prevé que el 40 por ciento de las aplicaciones empresariales incorporará agentes de IA para tareas específicas antes de que termine 2026, frente a menos del 5 por ciento en 2025. El tráfico viene del software que usted ya compró, no solo de los proyectos que aprobó.
No es un modelo. No es una interfaz de chat, y comprar uno no le da a sus usuarios un mejor asistente. No es un framework de agentes, y no decide qué debe hacer un agente a continuación. No es un programa de gobernanza de datos: puede bloquear una salida, pero no puede decirle qué campos de su almacén están regulados. Y no es, por sí solo, una certificación de cumplimiento. Es plomería que hace exigibles los controles y recolectable la evidencia, que es la condición previa de todo lo demás y, por sí sola, no resuelve nada más.
La expansión indiscriminada del alcance es la forma más rápida de matar un proyecto de gateway. Lo siguiente le corresponde porque debe aplicarse de manera uniforme y no puede quedar en manos de cada aplicación.
Un gateway de IA no es una categoría de producto que haya que salir a comprar primero. Es un punto de estrangulamiento que hay que establecer: una sola ruta donde la identidad, la autorización, la política de contenido, el registro y la atribución de costos se aplican a cada llamada al modelo y a cada invocación de herramienta, de modo que la gobernanza la imponga la red y no la memoria de los desarrolladores.
Los tres se ubican cerca del centro de la ruta de una solicitud, y por eso se confunden en las conversaciones con proveedores. Resuelven problemas distintos, y la mayoría de las empresas terminará operando los tres.
Una secuencia realista en el mercado medio toma alrededor de dos trimestres. El orden importa más que las herramientas, y la primera fase es la que los equipos intentan saltarse.
Ponga el gateway en modo de monitoreo y enrute por él a los equipos dispuestos. No aplique nada. En paralelo, inventaríe lo que ya existe, incluida la IA incrustada por proveedores en herramientas que usted no consideraba compras de IA. Los registros de salida, el descubrimiento de SaaS y los reportes de gastos revelan cada uno una porción distinta; nuestra guía para descubrir e inventariar agentes de IA en la sombra cubre la mecánica. Usted está produciendo dos entregables: una línea base de tráfico real y una lista de los sistemas que se van a resistir.
Incorpore a dos o tres equipos cuya vida mejore con el gateway. Deles claves de proveedor que ya no tengan que administrar, presupuestos que puedan ver, conmutación por falla que no tuvieron que construir y un cambio de SDK o de URL base que toma una tarde. En esta etapa la adopción debe darse por demanda de los equipos, no por mandato. Si los equipos no se ofrecen como voluntarios, la experiencia de desarrollo está mal y aplicar políticas no lo va a arreglar.
Ahora convierta al gateway en la única ruta aprobada para las cargas de trabajo de IA nuevas, conectado a su canalización estándar de entrega para que un servicio nuevo reciba una identidad, un presupuesto y un conjunto de políticas por defecto y no por ticket. Este es un cambio en la forma en que se entrega software, y por eso corresponde a su práctica de AI DevOps y no a un proceso de excepciones de seguridad. Bloquee la salida directa hacia los proveedores en la capa de red, únicamente para los entornos nuevos.
Trabaje el inventario de la Fase 1 en orden de riesgo multiplicado por volumen, con responsables con nombre y fechas. Espere un conjunto residual de sistemas que genuinamente no pueden enrutarse por el gateway, casi siempre IA incrustada en SaaS. No finja que están cubiertos. Documéntelos como riesgo aceptado con controles compensatorios, y revíselos en la renovación, que es cuando usted tiene poder de negociación.
Los proyectos de gateway rara vez fallan por lo técnico. Fallan de cuatro maneras previsibles, y cada una tiene una respuesta de diseño.
Elija un conjunto pequeño de métricas que un CIO pueda leer en una sola lámina y que a usted le avergonzaría que fueran en la dirección equivocada.
La pregunta del gateway no es si centralizar, porque la centralización ya está ocurriendo en las hojas de ruta de sus proveedores, ocurra o no en su arquitectura. La pregunta es si el punto de control le pertenece a usted o a una plataforma a la que simplemente le compra más que a nadie. Un gateway propio mantiene en sus manos la elección de modelo, la residencia de datos y la evidencia. Un gateway heredado optimiza para el ecosistema de un solo proveedor, lo cual está bien hasta que deja de estarlo.
Elija según la condición y no según la marca. Herede el gateway integrado en su nube o plataforma de datos principal cuando en la práctica dependa de un solo proveedor y espere seguir así durante los próximos dos años: el ahorro en integración es real, y el costo de quedar atado es un costo que usted ya aceptó en otras partes de ese stack. Adopte un gateway independiente y neutral frente a proveedores cuando enrute a dos o más proveedores de modelos, cuando la elección de modelo sea una palanca comercial viva en sus negociaciones, o cuando necesite residencia de datos, custodia de claves o retención de evidencia que su proveedor de plataforma no pueda garantizar por contrato. Construya solo en el caso acotado en que la autorización a nivel de herramienta tenga que leer de un sistema interno de política o de derechos que ningún producto alcanza, y aun entonces construya el punto de decisión de política y compre el proxy que va delante. Si usted no puede nombrar cuál de esas tres condiciones le aplica, todavía no está listo para seleccionar un producto, y la fase de observación le dirá cuál es.
Empiece en pequeño y empiece por la fase de observación. La mayoría de las organizaciones que se estancaron lo hicieron porque intentaron aplicar políticas antes de saber qué tráfico existía, y gastaron su capital político discutiendo reglas para cargas de trabajo que nadie había contado.
Infonaligy es una firma de consultoría en IA y servicios de TI con sede en Dallas-Fort Worth que atiende de forma remota a clientes en todo el país. Ayudamos a los líderes de TI a diseñar y poner en marcha planos de control de IA: identidad para agentes, política a nivel de herramienta, registros que sobreviven a una auditoría y atribución de costos que finanzas va a aceptar. Si está dimensionando un gateway, construyendo agentes de IA a medida que van a necesitar uno, o extendiéndolo hacia una Automatización de Procesos más amplia, nuestro equipo de consultoría puede poner a prueba el diseño: hello@infonaligy.com o 800-985-1365.
Infonaligy apoya a líderes de TI y de seguridad desde nuestra base en Dallas-Fort Worth, con entrega remota para organizaciones en todo el país.
Un proyecto con Infonaligy comienza con un diagnóstico de dos semanas: qué tráfico de IA existe realmente en su entorno, quién es responsable de él, qué toca y cuánto cuesta. A partir de ahí diseñamos la capa de gateway, la identidad de los agentes, la autorización a nivel de herramienta, la política de contenido, el registro y la recuperación interna de costos, y luego lo desplegamos por fases que no frenan la entrega. Independiente de proveedores y construido sobre lo que usted ya opera.
Infonaligy