Actividades de tratamiento

El registro de actividades de tratamiento (RAT) es el inventario legal de todo lo que el colegio hace con datos personales. Cada actividad (processing_activity) describe una finalidad; su contenido vive en versiones selladas (processing_activity_versions), y sobre las actividades de alto riesgo se levantan evaluaciones de impacto (dpia_assessments, EIPD, Art. 15 ter). Por API puedes leer todo el registro y escribir el RAT; la autoría de EIPD es de consola.

La misma superficie para integradores partner está en Actividades de tratamiento (Partner API); el registro de riesgos asociado, en Riesgos.

El modelo de versionado

Una actividad publica su contenido en versiones inmutables y monotónicas:

• versionNumber crece de a uno; la actividad apunta a la vigente con currentVersionNumber.
• Cada versión queda sellada con noticeChecksum — SHA-256 sobre el contenido normativo (finalidad, aviso en lenguaje claro, base legal, modelo de consentimiento y sus opciones, resúmenes de retención/transferencia/automatización). Si el texto cambia, cambia el checksum: es la prueba de qué vio el apoderado.
• Publicar una versión nueva puede invalidar los consentimientos anteriores (invalidatesPreviousConsents): las solicitudes pending/granted de versiones previas pasan a invalidated y se dispara la recaptura. La respuesta te entrega los ids afectados.
• Lo que no envíes en la versión nueva (dataCategories, recipients, consentOptions) se arrastra desde la versión anterior; lo que envíes la reemplaza.
• Publicar cuenta como revisión: fija lastReviewedAt, calcula el próximo reviewDueAt y reabre las EIPD aprobadas de la actividad.

Listar actividades

curl -G "https://app.edugoverna.com/api/processing-activities" \
  -H "x-api-key: {tu_api_key}" \
  -d limit=25

{
  "processingActivities": [
    {
      "id": "a2f1…",
      "code": "ACT-004",
      "name": "Comunicaciones académicas",
      "status": "active",
      "treatmentRole": "controller",
      "actingOnBehalfOf": null,
      "lawfulBasis": "consent",
      "sensitiveLawfulBasis": null,
      "consentRequired": true,
      "involvesSensitiveData": false,
      "involvesMinorData": true,
      "includesAutomatedDecisions": false,
      "includesProfiling": false,
      "riskLevel": "medium",
      "isHighRisk": false,
      "currentVersionNumber": 2,
      "currentVersion": {
        "versionNumber": 2,
        "versionStatus": "published",
        "title": "v2 · salidas pedagógicas",
        "purposeSummary": "Informar y coordinar actividades académicas…",
        "consentModel": "bundled",
        "noticeChecksum": "9b1e…",
        "publishedAt": "2026-07-30T14:00:00.000Z"
      },
      "retentionPolicy": null,
      "dpiaAssessmentCount": 0,
      "reviewDueAt": "2027-07-30T14:00:00.000Z"
    }
  ],
  "meta": {
    "totalMatchedCount": 9,
    "limit": 25,
    "returnedCount": 9,
    "nextCursor": null,
    "hasMore": false
  }
}

El detalle (GET /processing-activities/:processingActivityId) agrega el historial versions[] (con consentRequestCount por versión), los consentRequestCounts de la actividad —el radio de impacto de la próxima publicación invalidante— y expande currentVersion con sus dataCategories[] y recipients[].

Publicar una versión nueva

curl -X POST "https://app.edugoverna.com/api/processing-activities/a2f1…/versions" \
  -H "x-api-key: {tu_api_key}" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "v3 · incluye fotografías",
    "purposeSummary": "Comunicaciones académicas y registro fotográfico de actividades.",
    "invalidatesPreviousConsents": true
  }'

{
  "activity": {
    "id": "a2f1…",
    "currentVersionNumber": 3,
    "currentVersion": {
      "versionNumber": 3,
      "versionStatus": "published",
      "noticeChecksum": "c7a2…"
    }
  },
  "invalidatedConsentRequestIds": ["b9d2…", "b9d3…"]
}

Las demás rutas del RAT

Tanto POST como PATCH aceptan treatmentRole, actingOnBehalfOf, sensitiveLawfulBasis e includesProfiling, con las normalizaciones del servidor: actingOnBehalfOf se limpia al pasar el rol a controller, y sensitiveLawfulBasis se limpia al dejar involvesSensitiveData en false.

Exportar el RAT

curl -G "https://app.edugoverna.com/api/processing-activities/export" \
  -H "x-api-key: {tu_api_key}" \
  -d format=xlsx \
  -o rat.xlsx

HTTP/1.1 200 OK
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Content-Disposition: attachment; filename="rat-2026-08-27.xlsx"

Evaluaciones de impacto (EIPD)

curl -G "https://app.edugoverna.com/api/dpia/screening" \
  -H "x-api-key: {tu_api_key}" \
  -d processingActivityId=a2f1…

{
  "activity": { "id": "a2f1…", "name": "Videovigilancia patios", "code": "ACT-011" },
  "screening": {
    "level": "required",
    "letters": ["c"],
    "factors": ["declared_high_risk"],
    "reasons": ["La actividad declara observación sistemática…"]
  },
  "letters": [
    {
      "letter": "c",
      "legalText": "…",
      "schoolMeaning": "Cámaras u observación sistemática de espacios…",
      "reason": "…"
    }
  ],
  "existingAssessmentId": null,
  "existingAssessmentCode": null,
  "suggestedTemplates": [
    { "key": "cctv", "name": "Videovigilancia escolar", "whenToUse": "…" }
  ]
}

Cómo leer el screening

existingAssessmentId y existingAssessmentCode apuntan a la evaluación viva más reciente de la actividad (draft, in_review, approved o under_revision); una archivada o reemplazada no cuenta. Si vienen con valor, lo que corresponde es continuar esa evaluación, no abrir otra.

level es la respuesta (required, recommended o not_required) y llega acompañada de por qué:

• letters son los casos que el Art. 15 ter "requiere siempre": a decisiones automatizadas con efectos jurídicos significativos · b tratamiento masivo o a gran escala · c monitoreo sistemático de una zona de acceso público · d datos sensibles bajo una excepción del consentimiento. Cualquiera de ellas deja level: "required".
• factors son las señales del inciso general: declared_high_risk, sensitive_data, international_transfer, profiling, minor_data.

minor_data y profiling son agravantes, no gatillos. Por sí solos dejan la evaluación en recommended; acompañando a cualquier otra señal, entran a reasons y la evaluación queda required.

Que includesProfiling no dispare por sí solo es deliberado: la letra a) exige "efectos jurídicos significativos", y elaborar perfiles sin decidir nada sobre el estudiante no la configura. Eso sí, obliga igualmente a informarlo en la política pública (Art. 14 ter l), que pide declarar la existencia de decisiones automatizadas incluida la elaboración de perfiles). Un colegio que además decide sobre esos perfiles marca includesAutomatedDecisions, y ahí sí es la letra a).

El piso de impacto para NNA

Al escribir un escenario (POST /dpia/:assessmentId/scenarios, sesión + dpia.write) rige un piso: si la evaluación cuelga de una actividad con involvesSensitiveData: true, el escenario declara affectedSubjectTypes con student y el inherentImpact queda bajo 3 (Significativo), hay que fundamentar la calificación por escrito en impactRationale.

La regla es asimétrica según el origen de la fila:

El piso nunca altera el puntaje: no sube el impacto ni cambia el nivel. Sólo exige que la calificación baja quede defendida, que es lo que la hace sostenible ante la Agencia en los dos sentidos.

Los escenarios aceptan además probabilityRationale e impactRationale como fundamento separado de cada eje (hasta 2.000 caracteres cada uno), distintos de la justification general del escenario.

Rutas de EIPD

POST /dpia, PATCH /dpia/:id y POST /dpia/templates/:key/adopt aceptan interviewConversationId (uuid): la conversación de la entrevista que redactó la evaluación, que queda en metadata.interviewConversationId. El adopt acepta además summary, necessityAssessment, proportionalityAssessment y mitigationPlan, que reemplazan el borrador de la plantilla sin marcar ninguna sección como revisada. Al editar, una sección queda marcada «editada» sólo si su texto cambió de verdad.

Los escenarios de una EIPD comparten catálogo de medidas y matriz con el registro de riesgos.