PENSAMIENTO FUTURO

El runtime es gobernanza: cómo FayGer mantiene la IA controlable y auditable en cualquier terminal

Cuando se habla de seguridad en IA, lo primero que aparece suele ser «alineación del modelo».
Importa, sí, pero no es la imagen completa.

En cuanto la IA empieza a tomar el mando de los terminales, a operar el software en tu lugar y a prestar servicios públicos para una organización, lo que realmente puede empujar a la sociedad al pánico no es una alucinación puntual, sino la pérdida sistémica de control:
no sabes dónde se ejecuta, no sabes qué permisos ha recibido, no sabes qué acaba de hacer y, sobre todo, no sabes a quién pedir cuentas, cómo detenerla, cómo revisar lo ocurrido o cómo presentar una reclamación.

A este riesgo lo llamo «acción en estado libre».
En el momento en que se permite a la IA actuar en estado libre, ningún argumento de producto y ningún «hemos puesto medidas de seguridad» aguantará al siguiente incidente.

Por eso insisto: la IA no se puede dejar a su aire; tiene que actuar bajo tutela humana.
Suena a postura, pero en términos de ingeniería se traduce en algo concreto: un sustrato de ejecución coherente entre terminales, lenguajes y proveedores que convierta la tutela, el aislamiento, la auditoría y la revocación en valores por defecto.
Para eso existe FayGer.

1. Por qué el «runtime» se vuelve infraestructura de gobernanza en la era de la IA

En la era del software tradicional, el runtime era sobre todo una comodidad de ingeniería:
la JVM permitía compilar Java una vez y ejecutarlo en cualquier sitio; Docker hacía que las imágenes se desplegaran de forma estable en máquinas distintas; WASM/WASI dejaba correr el código dentro de un sandbox.

En la era de Fay (iFay/coFay), el runtime ya no es solo comodidad: se convierte en infraestructura de gobernanza. Porque Fay no se limita a calcular, actúa hacia fuera:
manda mensajes, envía formularios, opera terminales, llama al hardware, dispara pagos, coordina drones... Acciones con consecuencias reales.

Si dejas que cada Fay corra «por su cuenta» en distintos terminales, hosts y cadenas de syscalls, llegas a lo más temible:
la fragmentación de la semántica de tutela.
En un dispositivo el freno funciona, en otro no; en un sistema hay auditoría, en otro solo fragmentos de log; en una versión los permisos están limitados, en otra se han abierto en silencio.

No es solo un problema de ingeniería, es un problema social.
Porque cuando ocurre un incidente, esas «diferencias de entorno» son las que rompen la cadena de responsabilidad.

2. La posición de FayGer: como la JVM o Docker, pero para una «ejecución gobernable»

FayGer en una frase: el entorno de ejecución virtual del ecosistema Fay.
Acepta un artefacto Fay (BuF) distribuible, cargable y verificable, y lo ejecuta de forma coherente en distintos terminales.

Pero lo que me importa no es «si corre», sino cómo corre.
Su promesa central se resume en cuatro palabras: coherente, aislado, demostrable, observable.

La analogía:

  • Para el bytecode de Java: a la JVM no le importa tu lógica de negocio, pero sí cómo se carga, verifica, ejecuta y aísla.
  • Para las imágenes de contenedor: Docker / OCI Runtime no se mete con lo que hace tu aplicación, pero sí dicta la estructura de la imagen, los permisos, las cuotas de recursos y los límites de ejecución.

FayGer hace lo mismo. No fija cómo se escribe la frontera de capacidades de una Fay (eso es asunto del protocolo y de las habilidades). Lo que fija es: cuando una Fay se entrega a la sociedad, en qué «postura gobernable» tiene que ejecutarse.

3. Por qué importa la estructura en tres capas: Loader / Runtime / Adapter

FayGer se divide en tres capas, y esa división es clave para la gobernanza:

  1. Capa de carga (Loader)
    La frontera entre el BuF y el mundo exterior. Se ocupa de la lectura, la validación estructural, la negociación de versiones, la verificación de firma y la política de carga (Eager/Lazy).
    La pienso como la aduana: si tu estructura no encaja, no entras; si no llevas firma, no entras; si tu versión no encaja, no entras.

  2. Capa de ejecución (Runtime)
    La que ejecuta la semántica de BuF. Permite que múltiples implementaciones en distintos lenguajes (Rust / Go / TypeScript...) sean intercambiables a través de una interfaz unificada.
    Esto resuelve un problema que se suele ignorar: si atas el runtime a un único ecosistema de lenguaje, atas la gobernanza a una empresa o a una toolchain, y acabas con un monopolio de hecho.

  3. Capa de adaptación (Adapter)
    La frontera entre FayGer y el terminal anfitrión. Traduce las Universal Instructions a llamadas al sistema y, en sentido inverso, convierte la respuesta del sistema en eventos auditables.
    La pienso como la compuerta de permisos: qué capacidades concede el terminal, cuántas y con qué granularidad debe negociarse y limitarse aquí.

El valor de las tres capas: meter la «semántica de gobernanza» en capas estables, no dejarla dispersa por los detalles de cada terminal.
La gobernanza no puede depender de la conciencia de cada equipo, tiene que imponerla la arquitectura.

4. «Controlable» no es un botón, sino un conjunto de defaults

Cuando digo «la IA tiene que actuar bajo tutela», no estoy pidiendo un interruptor en la UI.
Pido un conjunto de defaults que no se puedan saltar, y FayGer es el lugar adecuado para alojarlos.

Algunos puntos que considero deberían estar fijados como defaults del runtime:

4.1 Negociación de capacidades y mínimo privilegio

Las capacidades del terminal deben declararse, negociarse y otorgarse, no «si el programa puede llamarlo, lo llama».
Si a un BuF no se le ha concedido capacidad de escritura en el sistema de ficheros, no puede escribirla «de paso» aprovechando algún fallo del SO.

Cuando la sociedad empiece a depender de coFay para servicios públicos, esto se vuelve aún más sensible:
si los límites de permiso de un rol público no están claros, la eficiencia se convierte en poder.

4.2 Cuotas de recursos y radio de daño

Las cuotas de CPU / memoria / red / almacenamiento de una Fay son, en el fondo, su radio de daño.
No se puede contar con que «el modelo se contenga»: solo se ponen límites duros desde el runtime.

4.3 Observabilidad: que la auditoría no sea un parche posterior

En muchos sistemas la auditoría se añade después de un incidente.
En el caso de Fay tiene que ser una capacidad por defecto; si no, la responsabilidad nunca se podrá rastrear hasta el final.

Mi enfoque preferido: que el runtime ofrezca un modelo de error unificado, con marcas de capa de origen y cadena de causas, y errores estructurados; y que los eventos de ejecución clave formen un flujo de auditoría que se pueda suscribir, agregar y congelar.
Silencioso por defecto (no molesta a nadie), pero recuperable por completo cuando hace falta.

4.4 «Detener el efecto exterior» tiene prioridad

Cuando la relación de tutela no se sostiene, cuando el responsable es inalcanzable o cuando el sistema entra en un estado incierto, prefiero que Fay se pare.
No por conservadurismo, sino por respeto a la estructura de responsabilidad:
mejor dejar la tarea sin acabar que seguir actuando hacia fuera sin nadie a cargo.

Si esta política se reparte por el código de negocio, los KPI acabarán erosionándola; metida en el runtime, tiene la oportunidad de convertirse en regla social.

5. FayGer e iFay/coFay: no resuelve todo, pero decide si el suelo aguanta

No considero a FayGer una panacea.
Identidad, fronteras de personalidad, semántica de protocolo, mecanismos de reclamación, consenso de contribución... cada cosa necesita su propia capa.

Pero FayGer decide algo más fundamental:
una vez que escribes estas ideas en documentos, protocolos y manifiestos, ¿se mantienen intactas cuando llegan a un terminal real?

En la Fase 1 puedes dejar que iFay simule operaciones de UI.
En la Fase 2 puedes tomar el control del terminal vía CAP/DTP.
En la Fase 3 puedes invocar habilidades en red mediante protocolos remotos.
En la Fase 4 puedes hacer que iFay y coFay colaboren.
En la Fase 5 puede que incluso toque hablar de distribución de valor en una era pos-monetaria.

Pero pase lo que pase, la frase básica no debería cambiar:
la IA no se puede dejar a su aire; tiene que actuar bajo tutela humana.

La tarea del runtime es convertir esa frase humana en un hecho que el sistema no pueda esquivar.

6. Cierre: el miedo del futuro no es «la IA es muy potente», sino «la IA es muy potente y no se puede gobernar»

Hoy gran parte del miedo a la IA es miedo al desempleo, a empobrecerse de nuevo y al colapso del sentido.
Entiendo esos sentimientos.

Pero si de verdad vamos a una era de abundancia productiva, el derecho a vivir no debería seguir secuestrado por el trabajo.
Lo que decidirá si la sociedad es estable será la gobernanza: si la responsabilidad puede rastrearse, si las reclamaciones tienen un punto de entrada, si los servicios públicos se auditan, si privilegio y voz crecen en proporción a la contribución.

Y el primer paso de la gobernanza es hacer gobernable la propia ejecución de la IA.
Para mí, FayGer es el cimiento que no se puede esquivar.

Documentos relacionados