La mayoría de las universidades no decidieron adoptar la IA; llegó sin más. El profesorado redacta con ella, los estudiantes programan con ella, los grupos de investigación conectan agentes a cuentas de laboratorio compartidas y a datos departamentales, y el departamento central de IT se entera después. La investigación de EDUCAUSE (2025) describe la brecha sin rodeos: el uso de la IA está ya extendido entre el profesorado y el personal de educación superior, mientras la gobernanza formal de la IA y la cobertura de la política de uso aceptable se quedan atrás. Una política que nadie puede ver, y que nada hace cumplir, no es un control: es un PDF.
Esa brecha no es exclusiva del campus, pero el campus la agudiza. Las cuentas son compartidas por diseño. La integridad de la investigación depende de saber qué tocó qué. Y las personas a las que más quieres habilitar —los investigadores— son precisamente quienes un control de mano dura empujaría hacia herramientas en la sombra.
El problema, en concreto
En una red de campus suelen darse tres cosas a la vez:
- La política de uso aceptable existe, pero no se hace cumplir. Hay una norma sobre qué sistemas puede tocar la IA y qué puede hacer. Nada convierte esa norma en una decisión en el momento en que un agente intenta actuar.
- Las cuentas compartidas borran la atribución. Los agentes de un laboratorio se ejecutan como una única cuenta de servicio detrás de un pool de conexiones. La auditoría nativa atribuye el acceso a esa credencial, no a la persona ni al agente que realmente lo hizo.
- Los investigadores necesitan moverse rápido. Quieren probar hoy un agente nuevo contra datos más o menos reales, no abrir un ticket y esperar. Si la gobernanza es una barrera que tienen que suplicar para superar, la rodean.
Es la misma forma que está golpeando al mercado en general. De las organizaciones que sufrieron una brecha relacionada con la IA, alrededor del 97 % carecía de controles de acceso a la IA adecuados (IBM Cost of a Data Breach 2025, Ponemon), y Gartner espera que más del 40 % de los proyectos de IA agéntica se cancelen antes de finales de 2027: la deuda de gobernanza es buena parte del motivo. La versión del campus es más barata de arreglar pronto, cuando los agentes son pocos y el radio de impacto es pequeño.
Cómo ayuda Olivares AI
Olivares AI es una plataforma abierta y autoalojable que descubre los agentes de IA en tu infraestructura, mapea lo que cada uno puede leer y escribir, y te permite gobernar y auditar ese acceso. Es read-first: observa y registra fuera de banda antes de restringir nada, y es deny-closed allí donde sí restringe. Para un campus eso significa que puedes empezar viendo la verdad, y solo entonces decidir qué hacer cumplir.
Hacer cumplir la política de uso aceptable, deny-closed
La capa de gobernanza convierte la AUP en una política que produce una decisión. Su motor ABAC se ejecuta después del acceso basado en roles y solo puede restringir más: deniega cuando coincide una regla de denegación, en caso contrario se mantiene la decisión existente, y una política malformada falla cerrada en lugar de abierta. Así, una regla del tipo «ningún agente de IA puede escribir en el sistema de calificaciones» o «los agentes de sandbox no pueden llegar al SIS» se convierte en una denegación aplicada, no en un memorándum.
Sé preciso sobre lo que la v1 cubre. Las reglas de denegación de hoy se basan en el principal, el permiso/verbo y el recurso: los atributos que realmente llegan al evaluador. Las reglas que se ramifican según la sensibilidad del recurso (por ejemplo, «cualquier cosa etiquetada como FERPA») necesitan una junta de atributos de recurso que es un follow-up documentado, todavía no entregado. Donde necesitas a una persona en el bucle, la plataforma registra una solicitud de aprobación más un rastro de decisiones de solo adición, de modo que «quién aprobó que este agente llegara a ese dataset» tiene respuesta más adelante.
Consulta /docs/concepts/governance para el modelo read-first, deny-closed y dónde la actuación está en producción frente a bajo demanda.
Atribuir quién hizo qué entre cuentas compartidas
Esta es la capacidad de carga para el campus. El mapa de acceso registra, con niveles de confianza honestos, qué agente lee o escribe qué recurso y si ese acceso está permitido o solo observado. La gobernanza de identidad (/product/identity) vincula un agente a la identidad canónica que presenta su credencial, de modo que un acceso pueda atribuirse con firmeza.
La regla de honestidad importa aquí más que en ningún otro sitio: la atribución es firme solo cuando se propaga una identidad por agente o por sesión hasta el acceso. Cuando varios agentes se ejecutan como una única cuenta de laboratorio compartida detrás de un pool, la atribución colapsa a esa única identidad, y el producto lo dice, exponiendo el binding compartido como un hallazgo de gobernanza en lugar de adivinar una persona. Una identidad vinculada a más de un agente se marca, no se tapa. El remedio es operativo: propagar la identidad por agente (por ejemplo, en el nombre de aplicación de la conexión) y la atribución se afina. No imprimiremos un nombre que las señales no puedan sustentar.
Sandboxes gobernados para investigadores
Los investigadores obtienen una ejecución aislada y efímera de escenarios de agentes contra recursos simulados (mocked), no de producción. El runner de sandbox por defecto está aislado por construcción: no mantiene ningún handle a tu store, red o secretos, y un paso que pide un recurso que el escenario no simuló devuelve un marcador determinista de mock-miss en lugar de llegar a algo real. Las ejecuciones son efímeras; cada una registra el runner real y si estaba aislado, de modo que un backend degradado es visible, nunca se oculta. Un aislamiento más fuerte a nivel de SO (un contenedor endurecido o una microVM) es un backend conectable que el operador de autoalojamiento integra.
Esto le da a un laboratorio un lugar seguro donde probar un agente nuevo antes de que toque jamás datos reales, que es la forma de mantener a los investigadores que van rápido dentro de la gobernanza en lugar de rodearla. Para los agentes que sí gobiernan sistemas reales, una batería defensiva de red-team con consentimiento previo (prompt injection, jailbreak, exfiltración) puede sondear la resistencia de un agente, puntuada frente al OWASP Top 10 for Agentic Applications. Solo se ejecuta contra agentes que posees y has autorizado: es una suite de pruebas, no una herramienta ofensiva.
Evidencias para la integridad de la investigación y las auditorías
Las evaluaciones puntúan las salidas candidatas de los agentes frente a suites doradas versionadas, útil cuando un grupo de investigación necesita un registro reproducible de que un agente cumplió un criterio, ejecución tras ejecución. El juez es honesto: si no hay ningún backend de puntuación conectado, una ejecución se registra como skipped, nunca como un pase silencioso, y las salidas en bruto nunca se persisten: solo un hash unidireccional y una etiqueta depurada. Consulta /product/evals.
Para la institución, la capa de cumplimiento (/product/compliance) agrega lo que la plataforma ya observa y audita en un paquete de evidencias sellado y de solo adición, anclado a un ledger encadenado por hash. Un control con evidencia que lo respalda se marca como cumplido; uno sin ella se marca como gap, nunca como un pase falsificado. Esto es un mapeo técnico hacia marcos como el Reglamento de IA de la UE e ISO/IEC 42001: no es asesoramiento legal y el producto no afirma estar certificado.
Qué es esto, y qué no es
- Es una capa abierta y autoalojable de gobernanza y observación para la IA en tu infraestructura. El control plane puede ejecutarse offline / air-gapped en tu propio hardware, de modo que los datos de atribución y política nunca salen del campus.
- Es read-first y deny-closed. Observa y gobierna de forma amplia; no actúa de forma amplia. Donde puede ejecutar una acción, esa superficie está en producción, bajo demanda, o es una junta declarada, y el catálogo de módulos marca cuál.
- Es pre-1.0. El catálogo es de 23 módulos con aproximadamente 20 conectados; algunas de las capacidades anteriores están presentes, algunas son bajo demanda, algunas son follow-ups documentados. Etiquetamos cuál.
- No ejecuta tus modelos, y no es inferencia air-gapped. El air gap es el control plane. Solo los modelos autoalojados (vLLM, Ollama) se ejecutan offline; los modelos alojados como Claude no.
- No es una certificación. Sin certificación SOC 2 / ISO / Reglamento de IA de la UE: el mapeo de cumplimiento está «diseñado hacia» esos marcos y produce evidencias, no un sello. Consulta /security para la postura y /docs/concepts/governance para el modelo de gobernanza.
La adopción está extendida; lo que se queda atrás es la supervisión (EDUCAUSE, 2025). El punto de partida honesto es ver lo que tu IA ya toca, decidir qué puede hacer y demostrarlo, en ese orden.