La Arquitectura Empresarial de la IA

La inteligencia artificial ya se está extendiendo dentro de la mayoría de las organizaciones, muchas veces antes de que exista una estrategia formal. Los empleados utilizan asistentes de propósito general para resumir documentos, preparar presentaciones, revisar contratos, escribir código y organizar investigaciones. Algunas áreas contratan aplicaciones especializadas. Los equipos de desarrollo prueban APIs externas. El personal técnico también puede comenzar a ejecutar modelos de pesos abiertos sobre infraestructura propia.

Esta adopción suele avanzar de manera desigual. Cada equipo elige herramientas diferentes, aplica sus propios criterios y resuelve necesidades inmediatas sin analizar cómo esas decisiones encajan dentro de un entorno empresarial más amplio. Los resultados pueden ser útiles en el corto plazo, pero difíciles de administrar cuando el uso crece.

El desafío ya no consiste simplemente en decidir si se permite la IA. Consiste en organizar su uso sin crear una colección descontrolada de modelos, aplicaciones, conexiones de datos y procesos autónomos.

Esto requiere una estrategia de adopción y una estrategia de arquitectura. La empresa debe decidir cómo se accederá a la IA, dónde se ejecutarán los modelos, qué datos podrán utilizar, cómo se aprobarán las aplicaciones, qué controles se aplicarán y quién conservará la responsabilidad sobre los resultados.

Estas decisiones son más fáciles de tomar antes de que la IA quede incorporada al trabajo cotidiano. Una estructura inicial débil puede corregirse, pero el costo aumenta cuando los usuarios ya dependen de ciertas herramientas, los equipos han creado integraciones y la información sensible circula por sistemas que nunca fueron diseñados para ser gobernados a escala.

Diseñar la adopción desde el comienzo

Muchas organizaciones comienzan con una prueba piloto basada en un asistente comercial o en un pequeño conjunto de aplicaciones aprobadas. Es un punto de partida razonable, pero el piloto debería utilizarse para definir el entorno futuro, no solo para medir el uso.

La primera etapa debe mostrar qué tipos de trabajo se benefician con la IA, qué riesgos aparecen en la práctica y qué controles serán necesarios cuando la adopción aumente. También debe establecer límites de uso antes de que los hábitos informales se conviertan en prácticas permanentes.

Una estrategia sólida no necesita anticipar todas las aplicaciones futuras. Sí debe definir qué categorías de información pueden procesarse, qué herramientas están autorizadas para cada categoría, qué actividades requieren revisión humana y qué integraciones necesitan evaluación técnica o de cumplimiento.

También debe distinguir entre productividad personal y sistemas operativos. Pedirle a un asistente que mejore un memo interno no es equivalente a permitir que un agente modifique un registro de clientes, apruebe un pago o prepare una presentación regulatoria. Ambas actividades utilizan IA, pero pertenecen a niveles de riesgo diferentes.

Esta distinción importa porque la adopción suele avanzar desde la asistencia hacia la ejecución. Cuando un modelo puede acceder a datos internos, utilizar herramientas o iniciar acciones, pasa a formar parte del entorno operativo. El gobierno debe ampliarse en consecuencia.

El objetivo no es centralizar cada experimento. Es permitir que los equipos exploren sin que las iniciativas locales produzcan una infraestructura que la organización ya no pueda comprender ni controlar.

Plataformas comerciales o modelos de pesos abiertos

Una de las primeras decisiones se relaciona con el tipo de modelos que utilizará la empresa.

Las plataformas comerciales como ChatGPT, Claude y otros servicios administrados ofrecen modelos avanzados, administración empresarial, interfaces accesibles e infraestructura operada por el proveedor. Suelen ser la vía más rápida hacia una adopción amplia porque la empresa no necesita desplegar ni mantener la infraestructura subyacente.

Los modelos de código abierto o de pesos abiertos ofrecen otra alternativa. Pueden ejecutarse sobre infraestructura elegida por la organización, adaptarse a aplicaciones específicas y utilizarse cuando se necesita mayor control sobre los datos, la latencia, los costos o el comportamiento del modelo.

La elección suele presentarse como una oposición entre comodidad y control, pero la decisión real depende de la tarea, la sensibilidad de la información, el volumen esperado, las necesidades de integración y la capacidad técnica de la empresa.

Los modelos comerciales pueden resultar adecuados para investigación, redacción, resumen, asistencia de programación y análisis de bajo riesgo. Un modelo privado puede ser más apropiado para procesar documentos confidenciales, asistir sistemas internos, ejecutar tareas repetitivas de gran volumen o funcionar dentro de redes restringidas.

La calidad del modelo es solo un criterio. También deben analizarse las condiciones contractuales, la retención de datos, la ubicación del procesamiento, los controles de identidad, los registros, la estabilidad de las APIs, la disponibilidad, los precios, las actualizaciones y las opciones de migración.

Por eso, muchas empresas utilizarán más de un modelo. Un modelo comercial avanzado puede ocuparse del razonamiento complejo, mientras que otro más pequeño y privado realiza clasificación o extracción documental. Un tercero puede formar parte de una aplicación especializada desarrollada por un equipo interno.

El objetivo estratégico no es elegir un ganador permanente. Los modelos, los precios y los proveedores cambiarán. La decisión más duradera se relaciona con la capa que gobierna cómo se seleccionan, conectan y reemplazan.

Nube o infraestructura local

Elegir un modelo de pesos abiertos genera otra decisión: dónde se ejecutará y quién será responsable de operarlo.

Un modelo administrado por la empresa puede correr en una nube pública, una nube privada, un entorno de hosting administrado, un centro de datos corporativo o servidores locales. Cada opción modifica el equilibrio entre escalabilidad, costo, control y complejidad operativa.

La infraestructura en la nube ofrece capacidad flexible y acceso más sencillo a hardware especializado. También introduce dependencias relacionadas con la seguridad del proveedor, la configuración y la correcta separación de datos, redes e identidades.

Los servidores locales brindan un control más directo sobre el entorno físico y de red. Pueden ser adecuados cuando los datos deben permanecer en una ubicación definida o se busca limitar dependencias externas. También requieren hardware, redundancia, monitoreo, actualizaciones, respaldos, planificación de capacidad y personal técnico calificado.

Ejecutar un modelo internamente no elimina el riesgo. Transfiere una mayor parte de la responsabilidad a la organización.

La empresa debe proteger no solo el modelo, sino también el sistema operativo, las bibliotecas, los contenedores, las bases de datos, las conexiones de red, la capa de identidad, las interfaces de las aplicaciones y los registros. También debe gestionar vulnerabilidades, actualizaciones, recuperación y rendimiento.

Un sistema local mal mantenido puede ser menos seguro que un servicio comercial bien administrado. Un entorno privado correctamente operado puede ofrecer controles que una plataforma externa compartida no puede proporcionar.

La pregunta relevante no es si el modelo está dentro o fuera de la empresa. Es si el entorno elegido puede ser operado, protegido y auditado según el nivel requerido por el caso de uso.

Cumplimiento en el sistema completo

Los proveedores comerciales suelen publicar documentación de seguridad, informes de auditoría, condiciones de procesamiento de datos y certificaciones de cumplimiento. Son elementos importantes, especialmente en sectores regulados.

Sin embargo, no convierten automáticamente en conforme cualquier implementación.

Los empleados pueden enviar información que no debería salir de un sistema, conectar fuentes no autorizadas o utilizar resultados sin la revisión necesaria. Los permisos pueden ser demasiado amplios, los registros incompletos o las aplicaciones pueden utilizar el modelo de formas no contempladas en la evaluación original.

Lo mismo ocurre con los modelos locales. La infraestructura controlada por la empresa no vuelve al sistema conforme por defecto. La organización debe definir quién puede acceder, qué datos pueden procesarse, cómo se registra la actividad, cómo se validan los resultados y cómo se gestionan los incidentes.

El cumplimiento depende de la cadena completa: modelo, infraestructura, aplicación, usuario, fuente de datos, resultado y decisión comercial posterior.

Por eso, una lista de modelos aprobados no es suficiente. El mismo modelo puede ser adecuado para una aplicación e inapropiado para otra. Una herramienta de resumen conectada a información pública tiene un perfil de riesgo diferente al de un agente con acceso a nómina, archivos legales o registros de clientes.

Las empresas deben evaluar la IA a nivel de caso de uso. Necesitan saber qué datos ingresan, por qué se procesan, qué resultado se espera, dónde se almacena y si puede iniciar una acción.

Cuanto más importante sea la acción, más estrictos deberán ser los controles.

La capa de control

A medida que las empresas adoptan múltiples modelos y aplicaciones, necesitan una capa común de supervisión y aplicación de políticas.

Esta capa de control se ubica entre los usuarios, las aplicaciones, los modelos y los datos empresariales. Determina quién puede acceder a cada modelo, qué aplicaciones están autorizadas, qué fuentes de datos pueden consultarse y qué acciones puede realizar un modelo o agente.

También debe permitir registrar y monitorear la actividad, seleccionar modelos, aplicar políticas y escalar solicitudes que queden fuera de las condiciones autorizadas.

Algunas de estas funciones pertenecen a la seguridad tradicional: gestión de identidades, permisos, prevención de pérdida de datos y registros de auditoría. Otras son específicas de la IA: filtrado de instrucciones, restricciones de recuperación, evaluación de resultados, reglas de selección de modelos y autorización de agentes.

La revisión manual no será suficiente a gran escala. Se necesitarán controles automatizados para detectar información sensible, comportamientos inusuales, incumplimientos de políticas y acciones potencialmente riesgosas.

Los sistemas de IA también podrán supervisar a otros sistemas de IA. Un modelo secundario puede revisar resultados, verificar políticas, identificar afirmaciones sin respaldo o decidir si una acción requiere aprobación humana.

Estos sistemas no eliminan la supervisión profesional. Permiten extenderla a un volumen mayor de actividad.

La capa de control también debe preservar la trazabilidad. En cualquier proceso importante asistido por IA, la empresa debería poder reconstruir qué modelo se utilizó, qué información recibió, a qué herramientas accedió, qué produjo y quién aprobó la acción final.

Sin esa visibilidad, la responsabilidad se vuelve difícil de establecer.

Supervisión humana y agéntica

La revisión humana sigue siendo esencial en contextos legales, financieros, médicos, regulatorios o vinculados con la seguridad. Los profesionales responsables deben conservar la autoridad sobre los estándares aplicados, incluso cuando parte del proceso esté automatizada.

La supervisión también debe ser realista. Exigir que cada resultado sea revisado puede parecer seguro, pero pierde eficacia si los revisores están sobrecargados o comienzan a aprobar respuestas de manera rutinaria.

El nivel de revisión debe corresponder al nivel de riesgo.

Las tareas de bajo riesgo pueden requerir muestreos periódicos y monitoreo de desempeño. Las de riesgo medio pueden necesitar revisión antes de que el resultado se publique o ingrese en un sistema. Las actividades de alto riesgo pueden exigir autorización explícita de un profesional calificado.

La supervisión agéntica puede apoyar esta estructura. Los revisores automatizados pueden comparar resultados con políticas y fuentes, verificar campos obligatorios o detener una operación cuando la confianza es baja.

Estos controles forman parte del diseño del sistema, no reemplazan la responsabilidad. Un agente puede aplicar una regla, pero la empresa debe decidir cuál es la regla correcta, cómo se manejan las excepciones y quién responde cuando el sistema falla.

Esta combinación de supervisión profesional y automatizada será cada vez más importante a medida que la IA pase de generar contenido a interactuar directamente con procesos empresariales.

De las herramientas a una capacidad empresarial

La IA no debería administrarse como una colección de herramientas aisladas.

Debe tratarse como una capacidad empresarial compuesta por modelos, aplicaciones, infraestructura, acceso a datos, políticas y mecanismos de supervisión.

Esto no obliga a construir de inmediato una plataforma central compleja. Sí exige una dirección clara. La empresa debe decidir qué conviene estandarizar, qué puede permanecer en manos de los equipos y dónde son necesarios controles comunes.

Un camino práctico puede comenzar con un conjunto limitado de herramientas comerciales, reglas claras sobre datos y un proceso formal para evaluar casos de uso. Más adelante puede incorporar modelos privados, aplicaciones internas y sistemas agénticos más avanzados. La arquitectura debe permitir esa evolución sin obligar a reconstruir el modelo de gobierno en cada etapa.

La estrategia más sólida no es necesariamente la más centralizada ni la más ambiciosa técnicamente. Es la que se ajusta al riesgo, los recursos y la realidad operativa de la empresa, preservando al mismo tiempo la capacidad de evolucionar.

La adopción de IA continuará exista o no una estrategia completa. Los empleados seguirán probando herramientas, los equipos desarrollarán aplicaciones y los proveedores incorporarán funciones de IA a sus productos.

La decisión empresarial es si esos desarrollos se acumularán de manera independiente o formarán parte de un sistema coherente.

Cuanto antes se diseñe ese sistema, más sencillo será ampliar el uso de IA sin perder el control sobre los datos, la infraestructura y las decisiones que importan.