Pros y límites en una organización pequeña

Los beneficios reales de OSCAL se notan donde hay repetición y cruce: el mismo control que se copia en varios planes, el mismo perfil que se compara entre sistemas, los resultados que hay que convertir en acciones. Con datos estructurados, esas tareas pueden hacerse con un programa y repetirse sin errores de transcripción, y los cambios de una versión de perfil a la siguiente pueden compararse campo a campo.

Donde casi no aporta es donde el trabajo es criterio y conversación: entender un proceso, redactar un informe para el concejo, convencer a un dueño de sistema.

Antes de invertir en un formato conviene medir cuánto trabajo recurrente podría aliviar. Aquí la tabla marca las tareas que sí se benefician, con su frecuencia anual y su duración estimada por el equipo. El tiempo anual de una tarea es lo que dura cada vez por las veces que se hace.

Consulta SELECT * FROM tareas_candidatas.

Una cifra puede engañar cuando se mira por vez y no por año. La tarea más larga de cada ejecución no es siempre la que más tiempo se lleva al cabo de doce meses. Y entre las que no mejoran con datos estructurados, la que más consume sigue siendo trabajo humano que ningún formato resuelve.

Con una persona a media jornada, un cambio total es un riesgo en sí mismo. Una adopción razonable avanza por etapas: elegir una pieza con retorno claro (por ejemplo, el perfil y la lista de controles heredados), llevarla al formato, comprobar que alguien más puede leerla y solo entonces decidir si seguir. No hay proveedores que entreguen OSCAL todavía, así que no se puede depender de ellos para empezar.

Un documento OSCAL puede estar perfectamente formado, pasar un validador de esquema y describir un control que no opera. La validación comprueba la forma del archivo: que los campos existan y tengan el tipo correcto. No comprueba que lo escrito sea cierto. Eso sigue siendo trabajo de evidencia y de criterio.