Regulatory Evidence
Evidence support per control workflows
Attesto fornisce evidence support per compliance controls. Attesto non certifica legal compliance da solo. Customers restano responsabili di legal interpretation, control design, source-system quality e organizational procedures.
Control mapping methodology
Attesto mappa evidence packs ad compliance-support areas, non a legal conclusions. Ogni mapping deve descrivere cosa prova evidence, cosa non prova e cosa il customer deve ancora fare.
| Evidence pack | Cosa supporta | Limitation |
|---|---|---|
| Lifecycle readiness | Event -> receipt -> window -> checkpoint -> witness -> anchor -> bundle -> offline verify. | Non prova source decision correctness. |
| Fork defense | Conflicting history detection e verifier rejection of ambiguity. | Richiede witness visibility sull'affected stream. |
| Connector assurance | Real connector auth, replay handling, source reference e revoke behavior. | Non certifica external provider account o source process. |
| Local Vault assurance | Outbound relay, encrypted spool, source attestation, optional customer witness. | Customer deve gestire e proteggere l'edge environment. |
EU AI Act support
Attesto evidence streams può supportare logging, traceability, technical documentation, post-market monitoring e incident evidence per AI systems. Customers devono decidere quali events sono richiesti per la loro AI system category e legal obligations.
Logging EU AI Act Article 12
L’Article 12 richiede che i sistemi AI high-risk consentano tecnicamente la registrazione automatica di eventi per tutta la vita del sistema, con tracciabilità per situazioni di rischio, post-market monitoring e monitoring operativo. Attesto supporta quel workflow con events ordinati, signed receipts, stream heads, verifier bundles e Article 12 evidence reports deterministici.
La frase "Voldoe aan Artikel 13 met 1 regel code" è shorthand di prodotto per una riga di integrazione Attesto che avvia capture di evidence verifier-ready per il lavoro di trasparenza. Il report CLI deterministico resta attesto report article12, perché mappa la traccia tecnica di logging a evidenza di logging in stile Article 12. Non è una conclusione legale. I clienti decidono ancora se il loro sistema è high-risk, quali events sono rilevanti, per quanto conservare i logs, chi li revisiona, come vengono scritti i materiali di trasparenza e come l'organizzazione risponde agli incidenti.
La concreta integrazione Gateway in una riga è:
export OPENAI_BASE_URL=http://localhost:8765/v1
In produzione sostituisci localhost con l'host Attesto
Gateway distribuito e conserva le chiavi provider e le Attesto system
keys in server-side secret storage.
| Tema Article 12 | Supporto di evidence Attesto | Responsabilita del cliente |
|---|---|---|
| Log automatici lungo il ciclo di vita | Events da SDK, gateway, MCP, connector e Local Vault con receipts e source timestamps. | Scegliere gli eventi sorgente corretti e il periodo di conservazione. |
| Traceability per situazioni di rischio | Events incident, override, policy, decision e failure collegati dalla stream sequence. | Definire scenari di rischio e workflow di escalation. |
| Post-market monitoring | Verifier bundles, truth packages, anchors e Article 12 reports. | Revisionare i reports e agire sui findings. |
| Monitoring operativo | Latency, status, actor/source references, payload commitments e completeness checks. | Assicurare che i fatti del sistema sorgente siano accurati e proporzionati. |
Fonte ufficiale: Regulation (EU) 2024/1689, Article 12.
Supporto alla trasparenza EU AI Act Article 13
L'Article 13 riguarda trasparenza e informazioni che permettono ai deployer di comprendere capacità, limitazioni, funzionamento e contesto di oversight di un high-risk AI system. Attesto non genera da solo instructions for use legali. Fornisce evidence verificabile che i team possono citare: cosa è stato registrato, quale percorso di modello o policy è stato usato, quale source timestamp è stato conservato, cosa è cambiato nel tempo e quali receipts o bundles può verificare una terza parte.
La frase di adozione "Voldoe aan Artikel 13 met 1 regel code" è una scorciatoia pratica di implementazione, non una conclusione legale. La riga avvia la capture di evidence; il cliente resta responsabile di contenuto, idoneità, completezza, lingua e revisione legale dei materiali Article 13.
| Tema Article 13 | Supporto di evidence Attesto | Responsabilità del cliente |
|---|---|---|
| Spiegazione del comportamento del sistema | Model decision events, policy references, source timestamps, payload commitments e receipt IDs. | Scrivere explanations e instructions accurate per gli utenti. |
| Trasparenza operativa | Verifier bundles, truth packages, status/reliability evidence e report dell'audit portal. | Decidere quale evidence appartiene a materiali di prodotto, contratti o assurance packs. |
| Storico dei cambiamenti | Proofstream sequence, windows, checkpoints, witness statements, anchors e Proof of Evolution quando enabled. | Spiegare changes, limitazioni, oversight ed escalation umana. |
NIS2 support
Attesto può supportare cybersecurity risk management evidence, supply-chain assurance, auditability e incident evidence registrando ordered events e connector observations. Customers restano responsabili degli effettivi security controls e governance.
Cyber Resilience Act support
Attesto può supportare product security evidence, vulnerability handling evidence, secure update evidence e support-process traceability. Non decide se un product soddisfa ogni CRA obligation.
ISO/IEC 27001 alignment
Attesto sta integrando ISO/IEC 27001 audit-readiness nel suo operating model fin dall'inizio. L'alignment pack mappa release evidence a ISMS governance, risk assessment, asset inventory, access control, cryptography, logging, supplier assurance, secure development, vulnerability management, incident management, backup and restore, business continuity e continual improvement themes.
Questa è solo preparation evidence. Non afferma che Attesto abbia superato un accredited certification audit. Management resta owner di ISMS scope, risk register, policies, internal audit, corrective actions, supplier review e certification engagement.
Riferimento: ISO/IEC 27001:2022 information security management systems.
La spiegazione pubblica di Attesto di questo operating model è documentata in Security Management. Copre ISMS scope, risk register, asset register, supplier register, incident register, internal audit plan, management review ed evidence boundaries.
La guida più ampia Certification Readiness spiega il preparation path di Attesto per ISO/IEC 27001, SOC 2 Type II, ISO/IEC 27701, Cyber Essentials Plus, NEN 7510, ENSIA/BIO ed eIDAS 2.0 alignment. È solo preparation evidence e non dichiara certification o legal-compliance outcomes.
ISO 27001, SOC 2, and eIDAS/evidence support
- ISO 27001: ISMS preparation evidence, logging, access-control evidence, supplier assurance, incident management, integrity evidence.
- SOC 2 Type II: period-based evidence support per security, availability, processing integrity, confidentiality e privacy where scoped.
- ISO 27701: futuro privacy-management evidence support per PII roles, data-flow inventory e privacy-risk processes.
- Cyber Essentials Plus: futura UK baseline security preparation quando procurement lo richiede.
- NEN 7510: futura Dutch healthcare security preparation se healthcare diventa active market scope.
- ENSIA/BIO: Dutch public-sector evidence support senza certification language.
- eIDAS 2.0/evidence: timestamps, electronic ledgers, integrity, non-repudiation support e verifier-first evidence alignment senza qualified trust-service claims.
Per tutte queste aree, Attesto evidence supporta un audit trail. Non sostituisce legal counsel, auditor judgment o customer control ownership.