AoL from Run One

1. Resumen ejecutivo

Assurance of Learning (AoL), el aseguramiento del aprendizaje, es el mecanismo mediante el cual las escuelas de negocios demuestran que sus titulados adquieren realmente las competencias que prometen sus programas. En su forma actual, el AoL es en gran medida un ejercicio periódico de elaboración de informes: los coordinadores toman una pequeña muestra de artefactos, aplican rúbricas a posteriori y reúnen evidencias agregadas a nivel de programa a tiempo para la siguiente visita de acreditación. El estudiante individual —la unidad que realmente aprende— rara vez está presente en el rastro de evidencias.

Este libro blanco propone un estándar abierto, denominado provisionalmente AoL from Run One, para capturar, estructurar y exponer la evidencia de aprendizaje de cada estudiante desde la primera ejecución de cualquier actividad de aprendizaje, ya sea una simulación, una discusión de caso, un trabajo escrito, un ejercicio entre pares o una tutoría mediada por inteligencia artificial (IA). El estándar define un esquema común de evidencias, señales de integridad, un vocabulario de alineación con rúbricas, reglas de portabilidad y reglas de privacidad, de modo que la evidencia producida por cualquier herramienta conforme pueda agregarse, auditarse y volver a analizarse entre asignaturas, programas e instituciones.

El estándar es deliberadamente acotado en su alcance y permisivo en su adopción. Toma convenciones estructurales de 1EdTech Caliper Analytics, xAPI (antes Tin Can), Open Badges 3.0 y la familia W3C Verifiable Credentials 2.0, y está diseñado para que cualquier proveedor o equipo interno pueda implementarlo sin pagar licencias. Kudzu Partners tiene previsto aportar una implementación de referencia inicial y propone convocar un grupo de trabajo abierto, pero la especificación en sí está concebida para pertenecer a la comunidad: escuelas, organismos de acreditación, investigadores y proveedores edtech.

Adoptar AoL from Run One traslada el aseguramiento de un artefacto de informes periódicos a una propiedad del sistema continua, verificable y referida a cada estudiante. Reduce la carga de la acreditación, hace defendibles las decisiones de mejora de los programas y proporciona a los estudiantes evidencias transferibles de lo que realmente han hecho y demostrado.

2. El problema: el aseguramiento del aprendizaje como teatro

El AoL se introdujo con la intención correcta. Los organismos de acreditación —AACSB, EQUIS, AMBA, ACBSP— pidieron a las escuelas que fueran más allá de los indicadores de entrada (las cualificaciones del profesorado, la selectividad en la admisión, los fondos bibliográficos) y demostraran que los programas producen realmente los resultados de aprendizaje que afirman. Dos décadas después, la maquinaria construida para satisfacer esa exigencia rara vez la cumple.

Hoy, el ciclo típico de AoL en una escuela de negocios es más o menos así. Un comité define los objetivos de aprendizaje del programa. Los coordinadores de asignatura vinculan los trabajos a esos objetivos. Cada pocos años, una muestra de artefactos de los estudiantes —a menudo entre 20 y 40 por objetivo— se evalúa retrospectivamente con una rúbrica. Los resultados se agregan en un panel de indicadores, se redacta una narrativa y el expediente se cierra hasta la siguiente visita de renovación de la acreditación. Entre visitas, la recogida de evidencias permanece prácticamente inactiva.

De ello se derivan tres consecuencias, cada una de ellas corrosiva para la credibilidad del proceso. En primer lugar, la evidencia es retrospectiva. Las rúbricas se aplican después de que el aprendizaje haya tenido lugar, a menudo por profesores que no estaban presentes cuando se produjo el trabajo, sobre artefactos despojados de su contexto. Se califica el ensayo de un estudiante, pero normalmente faltan el enunciado al que respondió, los recursos a los que tuvo acceso, el número de revisiones que hizo y la retroalimentación que recibió por el camino.

En segundo lugar, el muestreo es agregado, no por estudiante. Los informes de AoL describen cohortes. Rara vez permiten que un organismo de acreditación, un director de programa o el propio estudiante respondan a la pregunta: ¿qué demostró realmente esta persona concreta, en qué condiciones, con qué nivel? El estudiante desaparece en un percentil.

En tercer lugar, el proceso está desconectado de las herramientas que producen el aprendizaje. Los sistemas de gestión del aprendizaje (LMS), las plataformas de simulación, las herramientas de discusión, los tutores de IA y los motores de evaluación generan flujos de eventos muy ricos. Casi ninguno de esos datos se captura de una forma que sobreviva a la plataforma, se alinee con un resultado de aprendizaje del programa o incorpore señales de integridad que un tercero pueda verificar. Los coordinadores acaban recodificando a mano lo que los sistemas ya sabían.

El resultado es un ritual de cumplimiento que consume cientos de horas de profesorado por ciclo, produce evidencias que en la práctica son infalsables y no puede reutilizarse para el fin operativo para el que se concibió: ayudar a los programas a mejorar, cohorte a cohorte. Los decanos lo saben. Los evaluadores de la acreditación lo saben. Los estudiantes, si se pararan a pensarlo, también lo sabrían.

Este documento no propone una nueva pedagogía ni un nuevo régimen de acreditación. Propone algo más acotado y más aplicable: un formato compartido y legible por máquina para la propia evidencia, capturada desde la primera vez que se ejecuta una actividad y lo bastante transferible como para servir a la mejora de los programas, a la acreditación, a la movilidad de los estudiantes y a la investigación independiente a partir de una única fuente de verdad.

3. Qué significa "From Run One"

La mayoría de los esfuerzos de estandarización en analítica educativa se han incorporado a posteriori a sistemas que no se diseñaron pensando en ellos. El resultado es previsible: cobertura parcial, correspondencias frágiles y plazos de implementación largos. AoL from Run One se ha diseñado en torno a una disciplina distinta: toda actividad apta para aportar evidencias de AoL debe emitir evidencias conformes desde la primera vez que se despliega con estudiantes reales.

En términos operativos, "from Run One" (desde la primera ejecución) significa tres cosas.

Significa que el esquema de evidencias forma parte de la definición de la actividad y no es un añadido posterior. Cuando un docente crea una discusión de caso, un escenario de simulación, un trabajo escrito o un ejercicio mediado por IA, los resultados de aprendizaje a los que apunta, las dimensiones de rúbrica que pondrá de manifiesto y los artefactos que conservará se declaran de antemano, en el mismo objeto que describe la propia actividad. La instrumentación no es un proyecto aparte.

Significa que cada ejecución de un estudiante produce un sobre (envelope) de evidencias completo, no uno muestreado. No existe la noción de "evaluar un subconjunto para el AoL". El sistema captura los eventos de decisión, los artefactos y las puntuaciones de rúbrica de cada estudiante en cada ejecución de cada actividad. La agregación se produce en fases posteriores; el registro primario es el de cada estudiante.

Significa que las señales de integridad se capturan en el momento de la emisión y no se reconstruyen después. Las marcas de tiempo, los identificadores de herramienta, las versiones de las instrucciones (prompts), los identificadores de modelo (cuando interviene la IA), los hashes de las entradas y las señales de autoría se adjuntan a cada registro de evidencia en el momento de escribirlo. Un revisor, tres años después, puede razonar sobre las condiciones en que se produjo la evidencia sin depender de la buena fe de la institución que informa.

La intención es que el AoL sea un subproducto de la instrumentación y no una actividad independiente de elaboración de informes. Si se hace bien, la evidencia necesaria para la acreditación, la necesaria para la mejora de los programas y la que un estudiante querría llevar consigo en adelante proceden todas de la misma fuente, y ninguna exige que un coordinador reconstruya nada a posteriori.

4. El modelo de evidencias

El estándar define cinco capas de evidencia. Cada capa tiene un esquema definido, un conjunto de campos obligatorios y unas reglas sobre lo que los implementadores pueden ampliar. Las capas que debe incluir un registro dependen del nivel de conformidad que declare (§5.8): el contexto, los eventos de decisión y los artefactos están siempre presentes; la alineación con rúbricas se añade en el Nivel 2 y las señales de integridad completas, en el Nivel 3. Dentro de una capa, los campos concretos pueden ser nulos cuando un determinado tipo de actividad no los produce.

4.1 Metadatos contextuales

Los metadatos contextuales sitúan la evidencia en el tiempo, en el programa y en la cohorte. Identifican la institución, el programa y la especialización, la asignatura y el grupo, el periodo académico, el tipo de actividad y su versión y, lo que es fundamental, los resultados de aprendizaje concretos sobre los que la actividad afirma aportar información. Los resultados de aprendizaje se referencian mediante identificadores estables, no mediante texto libre, para que las correspondencias sobrevivan a los cambios de redacción de los propios enunciados de los resultados.

Los metadatos contextuales recogen también la modalidad de despliegue: si la actividad se realizó de forma síncrona en clase o asíncrona como tarea, con supervisión (proctoring), a libro abierto, de forma individual o en equipo. Dos ejecuciones de la misma simulación en modalidades de despliegue distintas producen evidencias comparables pero no idénticas, y un analista que trabaje después con ellas debe poder distinguir cuál fue cuál.

4.2 Eventos de decisión

Los eventos de decisión son los momentos observables en los que un estudiante hace algo que la actividad está diseñada para suscitar: una elección en una simulación, una respuesta enviada, un mensaje en una discusión, una sugerencia de un interlocutor de IA aceptada o rechazada, una valoración entre pares dada o recibida. Cada evento tiene un tipo, una marca de tiempo, un actor, un destino opcional y una carga útil (payload) estructurada.

El vocabulario de eventos de decisión es intencionadamente abierto. El estándar especifica el sobre (event_id, event_type, actor_id, timestamp, sequence, payload, context_ref) y reserva un pequeño conjunto de tipos de evento básicos (submit, select, revise, discuss, peer_evaluate, receive_feedback, use_resource), pero se espera que los implementadores amplíen la lista de tipos para describir comportamientos propios de cada actividad. Las extensiones se alojan en un campo con espacio de nombres para que no entren en conflicto entre proveedores.

4.3 Artefactos

Los artefactos o entregables son los productos duraderos de una actividad que una persona —el docente, un evaluador externo, el propio estudiante— podría querer examinar: entregas escritas, archivos subidos, transcripciones de chat, capturas del estado final de una simulación, contenidos multimedia generados. Cada registro de artefacto incluye un hash del contenido, un tipo MIME, un tamaño, una declaración de autoría (estudiante, equipo, asistido por IA con el nivel de asistencia declarado) y una referencia de almacenamiento.

El almacenamiento de los artefactos en sí queda fuera del alcance. El estándar exige que los artefactos sean direccionables y que su integridad sea verificable, no que residan en ningún sistema concreto. Una escuela puede alojarlos en almacenamiento institucional, un proveedor puede alojarlos en el suyo propio y una cartera digital del estudiante puede guardar copias. Lo que debe cumplirse es que el hash del registro de evidencia coincida con el artefacto recuperado, esté donde esté.

4.4 Señales de integridad

Las señales de integridad permiten a un revisor razonar sobre las condiciones en que se produjo la evidencia. Incluyen identificadores de herramienta y de versión, hashes de versión del prompt o del escenario, identificadores y configuración del modelo de IA cuando corresponda, identificadores de sesión, señales aproximadas del entorno (clase de dispositivo, indicadores de fiabilidad de la red, estado de la supervisión si la hay, dentro de los límites fijados en el §8) y firmas criptográficas sobre el propio registro.

El estándar no exige ningún esquema de firma concreto. Exige que el esquema que se utilice se declare en un objeto proof en el sobre del registro (§5.1), con el algoritmo, el identificador de clave y el valor de la firma, siguiendo la misma forma adoptada por el W3C Verifiable Credentials Data Model. Así, la evidencia de AoL puede verificarse con herramientas ya creadas para la verificación de credenciales, sin introducir una infraestructura paralela.

4.5 Alineación con rúbricas

La alineación con rúbricas es el punto en el que la evidencia se convierte en aseguramiento. Cada registro de evidencia incluye cero o más puntuaciones de rúbrica, cada una de las cuales hace referencia a (a) la definición de la rúbrica, por identificador y versión; (b) la dimensión concreta que se puntúa; (c) la puntuación numérica o categórica; (d) la fuente de la puntuación (automática, docente, par, externa), y (e) una cita opcional de la evidencia, es decir, un puntero al evento de decisión o al fragmento de artefacto en el que se basó la puntuación.

Las definiciones de las rúbricas son objetos independientes, versionados y transferibles. Esto es importante: las rúbricas evolucionan. Poder afirmar que una cohorte de 2023 se puntuó con la rúbrica v1.2 mientras que la de 2026 se puntuó con la v1.4, y poder examinar las diferencias entre ambas, es un requisito previo para un análisis longitudinal defendible.

5. Especificación técnica

Esta sección presenta la estructura del registro con el detalle suficiente para empezar a desarrollar sobre ella. La especificación completa, incluidas las restricciones a nivel de campo y los vocabularios controlados, se publicará por separado junto con la implementación de referencia; este documento describe el registro solo en el nivel necesario para evaluar el enfoque.

5.1 Sobre

Todo registro de AoL from Run One, con independencia del tipo de actividad que lo haya producido, comparte un sobre exterior común:

{
  "aol_version": "0.1.0",
  "record_id": "urn:example:aol:example-bs:2026:run:8a3f...",
  "issued_at": "2026-09-14T15:22:41Z",
  "issuer": {
    "type": "Institution",
    "id": "https://www.example-bs.edu/",
    "name": "Example Business School"
  },
  "subject": {
    "type": "Learner",
    "id": "urn:example:learner:example-bs:2026:0f2c...",
    "pseudonymised": true
  },
  "context": { "comment": "ver 5.2" },
  "events": [ { "comment": "ver 5.3" } ],
  "artifacts": [ { "comment": "ver 5.4" } ],
  "integrity": { "comment": "ver 5.5" },
  "rubric_scores": [ { "comment": "ver 5.6" } ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofPurpose": "assertionMethod",
    "created": "2026-09-14T15:22:41Z",
    "verificationMethod": "did:web:www.example-bs.edu#aol-key-1",
    "proofValue": "z3M..."
  }
}

Los ejemplos de este documento utilizan el espacio de nombres urn:example:, reservado para documentación (RFC 6963), y hosts de example-bs.edu, y truncan los identificadores y los hashes con ...; son ilustrativos, no registros reales.

El sobre es compatible con JSON-LD, pero no requiere herramientas JSON-LD para producirlo ni para consumirlo. Los implementadores que quieran la semántica completa de datos enlazados pueden añadir un bloque @context; los que prefieran JSON plano pueden omitirlo. Los campos básicos son estables en ambos modos.

5.2 Bloque de contexto (mínimo)

{
  "institution": "urn:example:institution:example-bs",
  "program": "urn:example:program:example-bs:mba-full-time",
  "outcomes": [
    "urn:example:outcome:example-bs:mba:lg2.strategic-thinking",
    "urn:example:outcome:example-bs:mba:lg4.ethical-reasoning"
  ],
  "course": "urn:example:course:example-bs:strat-501",
  "section": "2026F-A",
  "activity": {
    "id": "urn:example:activity:example-vendor:market-entry-sim",
    "version": "2.3.1",
    "type": "simulation"
  },
  "deployment_mode": "in_class_synchronous_teams"
}

5.3 Bloque de eventos (mínimo)

[
  {
    "event_id": "urn:example:event:8a3f:001",
    "event_type": "select",
    "timestamp": "2026-09-14T15:04:12Z",
    "sequence": 1,
    "actor_id": "urn:example:learner:example-bs:2026:0f2c...",
    "context_ref": "urn:example:aol:example-bs:2026:run:8a3f...",
    "payload": {
      "prompt_id": "market-entry.q1",
      "option_selected": "B",
      "options_considered_ms": 47000,
      "reasoning_text_ref": "urn:example:artifact:8a3f:reasoning-001"
    }
  }
]

5.4 Bloque de artefactos (mínimo)

[
  {
    "artifact_id": "urn:example:artifact:8a3f:reasoning-001",
    "mime_type": "text/markdown",
    "size_bytes": 2184,
    "content_hash": "sha256-9b1c...",
    "authorship": {
      "type": "ai_assisted",
      "assistance_level": "feedback_only",
      "disclosed_by": "learner"
    },
    "storage_ref": "https://evidence.example-bs.edu/artifacts/8a3f/reasoning-001"
  }
]

5.5 Bloque de integridad (mínimo)

{
  "tool": { "id": "urn:example:tool:example-vendor:simulator", "version": "4.12.0" },
  "scenario_hash": "sha256-41de...",
  "ai": [
    {
      "role": "counterpart",
      "model_id": "example-model-2026-06",
      "settings_hash": "sha256-77a0..."
    }
  ],
  "session_id": "urn:example:session:8a3f...",
  "environment": {
    "device_class": "desktop",
    "proctoring": "none"
  }
}

El objeto proof que firma el registro completo se sitúa en el sobre (§5.1), no dentro de este bloque, para que un verificador pueda comprobarlo sin entender el resto del esquema.

5.6 Puntuaciones de rúbrica (mínimas)

[
  {
    "rubric_id": "urn:example:rubric:example-bs:strategic-thinking",
    "rubric_version": "1.4",
    "dimension": "problem_framing",
    "score": 3,
    "scale_max": 4,
    "source": "instructor",
    "evidence_ref": ["urn:example:event:8a3f:001", "urn:example:artifact:8a3f:reasoning-001"],
    "scored_at": "2026-09-16T09:11:00Z",
    "scorer_id": "urn:example:scorer:example-bs:faculty:jsmith"
  }
]

5.7 Estrategia de versionado

El estándar sigue el versionado semántico. Las versiones MAJOR.MINOR.PATCH se declaran en el campo aol_version de cada registro. Hasta la 1.0.0, las versiones se numeran 0.x y son borradores: cualquiera de ellas puede modificar el sobre, y las reglas de compatibilidad que se describen a continuación entran en vigor a partir de la 1.0.0.

Un incremento MAJOR indica un cambio incompatible en la forma obligatoria del sobre o en la semántica de un campo reservado. Se espera que las implementaciones admitan como máximo dos versiones mayores consecutivas a la vez, y las vías de migración deben documentarse en las notas de la versión.

Un incremento MINOR añade nuevos campos opcionales, nuevos tipos de evento reservados o nuevas entradas en los vocabularios controlados. Las implementaciones conformes existentes siguen siendo conformes; simplemente no rellenan los campos nuevos.

Un incremento PATCH se reserva para correcciones editoriales, aclaraciones no normativas y corrección de erratas. No cambia lo que una implementación debe hacer.

Las extensiones con espacio de nombres —tipos de evento propios de un proveedor, cargas útiles personalizadas, identificadores de rúbrica propios de una institución— se permiten en cualquier versión y quedan fuera de las garantías de compatibilidad entre versiones. Son la válvula de escape que mantiene reducido el núcleo.

5.8 Niveles de conformidad

Se definen tres niveles de conformidad para que la adopción pueda avanzar de forma gradual.

• Nivel 1DescriptivoLa implementación emite el sobre, el contexto, los eventos y los artefactos. Las puntuaciones de rúbrica pueden adjuntarse por un canal aparte. Es el nivel que puede alcanzar un LMS heredado con un adaptador de exportación sencillo.
• Nivel 2AseguradoTodos los requisitos del Nivel 1, más registros de alineación con rúbricas emitidos en el momento de la puntuación. Es el nivel que necesita un programa de AoL en funcionamiento.
• Nivel 3VerificableTodos los requisitos del Nivel 2, más señales de integridad y pruebas criptográficas suficientes para que un tercero pueda verificar el registro sin contactar con el emisor. Es el nivel que exigen los organismos de acreditación y los casos de uso de movilidad.

6. Patrones de implementación

El estándar está diseñado para que pueda alcanzarse desde tres puntos de partida característicos. Cada uno de los patrones siguientes esboza los cambios mínimos necesarios para alcanzar, como mínimo, la conformidad de Nivel 1.

6.1 Plataforma de simulación existente

Las plataformas de simulación ya modelan internamente las decisiones, los tiempos y los estados finales. Adoptar el estándar es, ante todo, un ejercicio de correspondencia de esquemas y de exportación, no una reescritura. Las tareas habituales son: (i) declarar sobre qué resultados de aprendizaje afirma aportar información cada escenario y registrarlos en la definición del escenario; (ii) hacer corresponder los tipos de decisión internos con el vocabulario de eventos del estándar, utilizando extensiones con espacio de nombres cuando la semántica interna no tenga un equivalente directo; (iii) emitir un registro por estudiante al finalizar la ejecución, firmado con una clave de la institución o del proveedor.

La capa de alineación con rúbricas suele ser la que más diálogo requiere con la escuela. Las simulaciones producen a menudo resultados numéricos —cuota de mercado alcanzada, cumplimiento del presupuesto, duración del ciclo de decisión— que deben traducirse en dimensiones de rúbrica que el programa reconozca realmente. El estándar no prescribe esta correspondencia; solo exige que la que se elija se declare explícitamente y esté versionada.

6.2 LMS existente

Los sistemas de gestión del aprendizaje son el caso más difícil, porque sus modelos de eventos son más superficiales y sus repositorios de artefactos, más heterogéneos. Una vía práctica hacia la conformidad de Nivel 1 pasa por la exportación de analítica que ya ofrece el LMS —la mayoría de las plataformas actuales hablan Caliper o xAPI en alguna medida— y transforma esos flujos en sobres de AoL a la salida.

Cuando el LMS ya habla Caliper, la correspondencia de eventos es en gran medida biunívoca: AssignableEvent, AssessmentEvent, MessageEvent y AnnotationEvent tienen equivalentes naturales entre los tipos de evento básicos del estándar. Las carencias suelen estar en la direccionabilidad de los artefactos (muchos LMS no ofrecen URI estables para los artefactos cuando se archiva una asignatura) y en la alineación con rúbricas (pocas herramientas de rúbricas de los LMS emiten hoy identificadores de rúbrica versionados). Un adaptador institucional suele resolver ambas.

6.3 Creación de contenidos nuevos

Para una escuela o un proveedor que desarrolla contenidos nuevos —un nuevo tutor de IA, una nueva actividad experiencial, una nueva evaluación—, el patrón se invierte: primero se declara el esquema de evidencias y el contenido se diseña en función de lo que debe emitir. Es el caso "from Run One" en su forma estricta. Las herramientas de autoría que adoptan el estándar como salida de primer nivel lo presentan como campos que el autor completa durante la creación, no como una lista de verificación de cumplimiento que se revisa en el despliegue.

En este patrón, se pide a los autores de la actividad que indiquen, en la fase de diseño, sobre qué resultados de aprendizaje aportará información la actividad, qué eventos de decisión suscitará, qué artefactos conservará y con qué dimensiones de rúbrica debería poder puntuarse la evidencia resultante. La actividad no puede desplegarse hasta que esas declaraciones estén completas. A cambio, no se requiere ningún trabajo de AoL a posteriori: la evidencia está disponible desde la primera cohorte.

7. Alineación con la acreditación

El estándar es deliberadamente neutral respecto a los organismos de acreditación. No implementa la rúbrica ni la plantilla de informe de ningún organismo. Sin embargo, aspira a producir evidencias que puedan utilizarse directamente en los formatos de informe que ya acepta cada uno de los principales organismos. La correspondencia que figura a continuación es orientativa, no exhaustiva, y se mantendrá como un anexo vivo de la especificación.

La finalidad de esta correspondencia no es reducir la acreditación a un ejercicio de exportación de datos. El juicio, la narrativa y la cultura del programa siempre formarán parte de la acreditación. La finalidad es eliminar la carga de la reconstrucción: que la narrativa trate de lo que el programa hizo con la evidencia y no de cómo se reunió esa evidencia.

8. Privacidad y derechos del estudiante

Un estándar cuyo registro primario es el estudiante individual es, inevitablemente, un estándar para el tratamiento de datos personales a gran escala. Cada registro conforme describe qué hizo una persona, cuándo, en qué condiciones y qué valoración recibió. Los datos de tiempos, las declaraciones de uso de IA y las señales del entorno son datos de comportamiento en el pleno sentido jurídico. Por ello, el estándar trata la privacidad como una restricción del propio formato y no como un detalle del despliegue que se deja en manos de los implementadores.

El estándar no puede, por sí solo, hacer que un despliegue sea lícito. Esa sigue siendo responsabilidad de la institución y de sus encargados del tratamiento conforme al régimen que les sea aplicable, ya sea el RGPD en Europa, FERPA en los Estados Unidos, la Ley Estatutaria 1581 de 2012 de Colombia u otra legislación comparable. Lo que el estándar sí puede hacer es garantizar que nada en el formato impida operar lícitamente con arreglo a cualquiera de ellos. Siete reglas sirven a ese fin.

Seudonimización desde el diseño. El subject de un registro es un seudónimo emitido por la institución, nunca un nombre, un número de estudiante ni una dirección de correo electrónico. La tabla que vincula los seudónimos con las personas la custodia la institución, fuera del repositorio de evidencias, y nunca viaja con los registros. Los proveedores y demás encargados del tratamiento solo trabajan con registros seudonimizados. Los datos seudonimizados siguen siendo datos personales: la regla reduce la exposición, pero no saca los registros del ámbito de aplicación de la normativa de protección de datos.

La institución es la responsable del tratamiento. Los registros conformes designan a la institución como emisora, y es la institución quien decide los fines, la base jurídica y el plazo de conservación de la evidencia. Un proveedor que emite registros lo hace por cuenta de la institución. El contexto del registro puede incluir un bloque privacy que declare el responsable del tratamiento, los fines a los que puede servir la evidencia y su categoría de conservación. El bloque es opcional en este borrador; se prevé que el grupo de trabajo lo haga obligatorio en el Nivel 2 antes de la versión 1.0.

{
  "privacy": {
    "controller": "https://www.example-bs.edu/",
    "purposes": ["assurance_of_learning", "program_improvement", "learner_portability"],
    "retention_class": "accreditation_cycle",
    "policy_ref": "https://www.example-bs.edu/privacy/aol-evidence"
  }
}

Señales de integridad mínimas. Las señales de integridad se limitan a lo que un revisor necesita para razonar sobre las condiciones en que se produjo la evidencia: identificadores de herramienta y de versión, hashes del escenario y del prompt, identificadores del modelo de IA y categorías generales del entorno, como el tipo de dispositivo o el estado de la supervisión. El estándar no reserva ningún campo para direcciones IP, ubicación precisa, dinámica de tecleo o de movimiento del ratón, grabaciones de cámara web o de pantalla ni datos biométricos, y los registros conformes tampoco deben incluirlos en extensiones. Cuando un sistema de supervisión produzca ese tipo de material, el registro podrá indicar que hubo supervisión; nunca contendrá ese material ni hará referencia a él.

Limitación de la finalidad. La evidencia se captura para tres fines declarados: el aseguramiento del aprendizaje, la mejora de los programas y la portabilidad para el propio estudiante. Utilizarla para cualquier otro fin, como la admisión, la selección de personal o los procedimientos disciplinarios, requiere una base jurídica distinta que el estándar no puede aportar. Una puntuación de rúbrica cuya fuente sea automated, incluida una puntuación propuesta por un evaluador de IA, no debe decidir por sí sola un resultado que afecte a un estudiante concreto; antes la revisa una persona. El Reglamento de Inteligencia Artificial de la UE clasifica como de alto riesgo los sistemas de IA destinados a evaluar resultados de aprendizaje, lo que conlleva obligaciones propias.

Supresión sin romper la integridad. Los registros firmados y enlazados mediante hashes son deliberadamente difíciles de modificar, lo que encaja mal con el derecho de supresión que asiste al estudiante. El estándar resuelve esta tensión manteniendo los datos personales fuera de todo aquello que deba permanecer inmutable. Un registro se suprime eliminando los artefactos del estudiante y la correspondencia del seudónimo y sustituyendo después el registro por una marca de supresión firmada (tombstone) que conserva su identificador y el hecho y la fecha de la supresión, pero ninguna evidencia. Los resultados agregados que ya se hubieran comunicado no se recalculan. Todo lo que se ancle fuera de la institución, por ejemplo en un libro mayor público, debe ser un hash sobre un lote de registros, nunca un hash del registro de un único estudiante ni un puntero a él.

Umbrales de agregación. Los agregados a nivel de programa que se compartan fuera de la institución, incluso con los organismos de acreditación y con el grupo de trabajo, ocultan cualquier cifra que describa a menos estudiantes que un mínimo declarado. Este borrador propone un valor por defecto de 20, que una institución puede elevar y que solo debería reducir por un motivo documentado. Las cohortes pequeñas, las especializaciones minoritarias y las combinaciones poco frecuentes de atributos son donde suele producirse la reidentificación.

El acceso del propio estudiante. Un estudiante puede obtener todos los registros de los que es sujeto, en el formato propio del estándar, junto con las definiciones de las rúbricas con las que se le puntuó. Es la misma propiedad que permite transferir la evidencia a una cartera digital del estudiante, y también sirve al derecho de acceso. Un estudiante puede impugnar una puntuación. Una puntuación impugnada nunca se modifica sobre el propio registro: se sustituye por un nuevo registro de rúbrica que hace referencia al original, de modo que tanto la impugnación como su resultado sigan siendo auditables.

9. Gobernanza del estándar abierto

Un estándar abierto no es lo mismo que un documento publicado. Requiere un proceso editorial, un procedimiento de toma de decisiones, una licencia y un conjunto de implementadores que puedan confiar en que seguirá siendo abierto. Esta sección describe el modelo de gobernanza propuesto para AoL from Run One.

Licencias. El texto de la especificación se publica con la licencia Creative Commons Attribution 4.0 (CC BY 4.0). Las implementaciones de referencia que aporte cualquier parte se publican con la Apache License 2.0. Ambas licencias se han elegido por su compatibilidad con los ecosistemas de código abierto edtech existentes y por la ausencia de obligaciones copyleft que pudieran disuadir a los implementadores comerciales.

Grupo de trabajo. Se convocará un grupo de trabajo de dirección con tres categorías de puestos: escuelas de negocios (decanos, vicerrectores académicos, coordinadores de AoL), representantes de los organismos de acreditación (como observadores o como miembros de pleno derecho, según prefiera cada organismo) e implementadores (proveedores edtech, equipos de ingeniería internos, investigadores). El reparto de puestos se inclina deliberadamente hacia las escuelas y los organismos de acreditación, no hacia los implementadores, para mantener la especificación alineada con las necesidades de información a las que existe para servir.

Proceso editorial. Los cambios en la especificación siguen un proceso público de propuestas de cambio inspirado en los procesos del IETF y del W3C. Cada cambio propuesto se registra como una propuesta numerada, se somete a un periodo obligatorio de comentarios públicos y, a continuación, el grupo de trabajo lo incorpora, lo aplaza o lo rechaza mediante votación. Las decisiones editoriales y las opiniones minoritarias se recogen en las notas de versión de la especificación.

Cadencia de versiones. Las versiones menores se publican con una cadencia previsible (inicialmente, cada seis meses). Las versiones mayores requieren tanto una mayoría cualificada del grupo de trabajo como evidencia de al menos dos implementaciones independientes de los cambios propuestos. Con ello se pretende evitar que la especificación avance más deprisa de lo que pueden seguirla sus implementadores.

Posición respecto a la implementación de referencia. Kudzu Partners aportará la implementación de referencia inicial y se compromete a mantenerla con licencia Apache 2.0 durante las dos primeras versiones mayores. La implementación de referencia no es la especificación. Si diverge de ella, prevalece la especificación y la divergencia se trata como un error de la implementación.

Precedentes. El modelo de gobernanza se basa directamente en el trabajo previo de 1EdTech, antes IMS Global (Caliper Analytics y, desde que la comunidad de Open Badges se integró en ella, Open Badges 3.0), de ADL y el IEEE (xAPI, normalizado como IEEE 9274.1.1) y del grupo de trabajo W3C Verifiable Credentials. No es novedoso; es deliberadamente convencional, porque una gobernanza convencional es lo que permite que la confianza se acumule a lo largo de varias versiones.

10. Hoja de ruta de adopción

La especificación solo tiene sentido si pasa del documento al despliegue. Se proponen cuatro fases.

Fase 0 — Especificación (del cuarto trimestre de 2026 al primer trimestre de 2027). Este borrador se publica para someterlo a comentarios públicos y se convoca el grupo de trabajo. La implementación de referencia se desarrolla en paralelo a partir del borrador, con el propósito explícito de sacar a la luz las ambigüedades del texto antes de su ratificación.

Fase 1 — Implementación de referencia y herramientas de código abierto (del primer al tercer trimestre de 2027). La implementación de referencia se publica con licencia Apache 2.0. Abarca la emisión de registros, la verificación, el almacenamiento de la alineación con rúbricas y un visor básico adecuado para coordinadores y revisores externos. Se publican bibliotecas complementarias en Python, TypeScript y Java para integrarlas en plataformas existentes. Se publican conjuntos de pruebas de conformidad para que cualquier implementación pueda autoevaluarse sin contactar con el grupo de trabajo. La primera versión estable (1.0.0) se ratifica al final de esta fase, una vez que la implementación de referencia y al menos una implementación independiente superen el conjunto de pruebas de conformidad: la misma regla de las dos implementaciones que deberán cumplir las versiones mayores posteriores.

Fase 2 — Primeros adoptantes (del tercer trimestre de 2027 al segundo trimestre de 2028). Una pequeña cohorte de escuelas de negocios —con el objetivo de reunir entre cinco y diez en la primera oleada, con distribución geográfica— despliega la especificación en producción. El compromiso no consiste en estandarizar de la noche a la mañana todo su programa de AoL, sino en instrumentar al menos una asignatura por programa con conformidad de Nivel 2 y compartir la evidencia resultante, agregada y sujeta a umbrales como se describe en el §8, con el grupo de trabajo para su revisión. Las aportaciones de los primeros adoptantes orientan las versiones menores 1.x.

Fase 3 — Integración con los organismos de acreditación (a partir del tercer trimestre de 2028). Con la evidencia de producción de la Fase 2 en la mano, el grupo de trabajo abre conversaciones formales con AACSB, EQUIS, AMBA y ACBSP sobre el reconocimiento de la evidencia conforme dentro de sus marcos de información actuales. La ambición no es cambiar lo que evalúan los organismos de acreditación, sino reducir la carga de información de las escuelas que ya producen evidencias en el formato del estándar. El reconocimiento puede avanzar a distinto ritmo con cada organismo; la especificación no depende del respaldo de ningún organismo en particular.

A lo largo de todas las fases, la métrica de éxito de la especificación es deliberadamente acotada: cuántos registros de estudiantes se produjeron con un esquema conforme en los doce meses anteriores, en cuántas instituciones y por parte de cuántos implementadores. Las conversaciones sobre gobernanza, los respaldos y la prensa son secundarios. Si no se está produciendo evidencia, el estándar habrá fracasado, independientemente de cómo se haya recibido.

11. Llamamiento a la acción

La formación en las escuelas de negocios ha dedicado dos décadas a construir el vocabulario de los resultados de aprendizaje y el ritual del aseguramiento sin llegar a construir nunca la infraestructura probatoria que daría sentido a ambos en el nivel del estudiante individual. La brecha es ya lo bastante grande como para constituir un problema de credibilidad para la propia acreditación, y puede cerrarse con herramientas que ya están disponibles.

Tres actores pueden hacer avanzar esta iniciativa, y cada uno tiene un primer paso concreto.

Los decanos y vicerrectores académicos pueden comprometer al menos una asignatura por programa con la conformidad de Nivel 2 en el curso académico 2027-2028, utilizando cualquier implementación de la especificación. El compromiso es pequeño, la evidencia producida puede utilizarse de inmediato en el siguiente ciclo de acreditación y el coste operativo es limitado, porque la especificación está diseñada para incorporarse a actividades que las escuelas ya están llevando a cabo.

Los organismos de acreditación pueden designar a un observador en el grupo de trabajo, sin comprometerse a respaldar el estándar. La observación no cuesta nada y proporciona al grupo de trabajo indicaciones directas sobre qué formatos de evidencia reducirían, en lugar de aumentar, la carga de las escuelas que acredita cada organismo.

Los proveedores edtech, los equipos de ingeniería internos y los investigadores pueden implementar la conformidad de Nivel 1 en al menos un componente de producto durante 2027, publicar el informe de conformidad y aportar al menos una mejora a la especificación. Una sola implementación no trivial contribuye más a la madurez de la especificación que cualquier cantidad de horas de comité.

Kudzu Partners ha publicado este borrador, publicará la implementación de referencia con licencia Apache 2.0 y acogerá las primeras reuniones del grupo de trabajo. El grupo de trabajo, la especificación y la implementación de referencia serán abiertos. Se invita a las instituciones y a las personas que deseen ser participantes fundadores a ponerse en contacto con el autor.

El aseguramiento del aprendizaje nunca se concibió como un teatro. Se concibió como evidencia: evidencia de que los programas cumplen lo que prometen, en el nivel de la persona a la que se hizo la promesa. Las herramientas para hacerlo realidad existen. Lo que falta es el formato compartido que les permita comunicarse entre sí y la disciplina para capturar la evidencia desde la primera vez que se ejecuta una actividad, y no la última vez antes de la visita de acreditación.

Para eso existe este estándar.

Apéndice A — Trabajos relacionados

La especificación se ha construido en continuidad consciente con varias iniciativas abiertas anteriores, y quienes la evalúen deberían leerla junto con ellas.

1EdTech Caliper Analytics (desarrollado cuando 1EdTech aún se llamaba IMS Global) define un vocabulario de eventos y una API de sensores para la analítica del aprendizaje. AoL from Run One reutiliza las formas de evento de Caliper cuando existen y trata los sistemas instrumentados con Caliper como fuentes de primer nivel.

xAPI (Experience API, antes Tin Can), custodiado por ADL y normalizado como IEEE 9274.1.1, define la estructura de declaraciones actor–verbo–objeto para los registros de experiencias de aprendizaje. La capa de eventos de decisión del estándar es estructuralmente compatible con xAPI y puede proyectarse, con pérdida de información, en un xAPI Learning Record Store cuando sea necesario.

Open Badges 3.0 / 1EdTech Comprehensive Learner Record definen estructuras de credenciales transferibles y modelos de verificación. AoL from Run One no compite con los estándares de credenciales; un registro de evidencia conforme puede referenciarse desde una credencial Open Badge o CLR como su evidencia subyacente.

W3C Verifiable Credentials Data Model proporciona las estructuras de prueba criptográfica adoptadas para el bloque de integridad del estándar, de modo que la evidencia de AoL pueda verificarse con las herramientas de credenciales existentes sin una infraestructura paralela.

Credenciales en poder del estudiante y verificables de forma independiente (Blockcerts, desarrollado originalmente en el MIT Media Lab con anclaje en cadena de bloques, y el trabajo del Digital Credentials Consortium sobre carteras digitales del estudiante) constituyen un precedente de portabilidad duradera de evidencias en poder del estudiante. El estándar no exige el anclaje en cadena de bloques, pero su estructura de prueba es compatible con él para las instituciones que quieran esa garantía.

Apéndice B — Glosario (selección)

Actividad. Unidad definida de experiencia de aprendizaje —un escenario de simulación, un trabajo, una discusión, una sesión de tutoría— que emite al menos un registro de evidencia por cada ejecución de un estudiante.

Aseguramiento del aprendizaje (Assurance of Learning, AoL). Proceso sistemático mediante el cual una institución demuestra que los estudiantes alcanzan los resultados de aprendizaje declarados.

Nivel de conformidad. Cada uno de los tres niveles declarados (Descriptivo, Asegurado, Verificable) que puede reivindicar una implementación y que corresponden a un grado creciente de completitud de la evidencia.

Evento de decisión. Momento observable de la interacción de un estudiante con una actividad que esta se diseñó para suscitar.

From Run One. Requisito de que una actividad conforme produzca evidencia completa desde la primera vez que se despliega con estudiantes reales, en lugar de incorporarla a posteriori.

Señales de integridad. Metadatos y pruebas criptográficas que permiten a un revisor verificar las condiciones en que se produjo la evidencia sin contactar con el emisor.

Seudónimo. Identificador que un registro utiliza para su estudiante, emitido por la institución y carente de significado sin la tabla de correspondencias que la institución custodia por separado. Los registros seudonimizados siguen siendo datos personales.

Alineación con rúbricas. Capa del modelo de evidencias en la que los eventos y artefactos observados se puntúan con una rúbrica versionada según dimensiones identificadas por su nombre.