aAmSemnat
§HCum construim

AI ca partener de cod, factor uman pe deciziile de securitate.

AmSemnat e construit cu Claude Code ca partener de pair programming. Asta înseamnă cod scris mai rapid și paritate cross-platform între SDK-uri. Nu înseamnă că lăsăm deciziile critice pe seama AI-ului. Uite mai exact unde intervine AI-ul în proces și unde rămâne factorul uman:

§01

De ce scriem despre asta

AmSemnat are de a face cu identitatea și semnătura - două dintre componentele critice pentru încredere într-un produs digital. Codul care le manipulează merită să fie auditabil. De aceea suntem deschiși despre cod, dar și despre cum producem codul. Nu ascundem AI-ul, nu îl etichetăm ca selling point. Îl prezentăm ca pe oricare alt instrument de coding - documentat, cu limitele lui, cu loc clar pentru factorul uman.
§02

Ce face AI-ul

Implementare, refactoring, scaffolding pentru teste, draft-uri de documentație, paritate cross-platform între SDK-urile Android, iOS și Expo. Concret - Claude Code ca partener de pair programming, scriind cod sub direcția unui developer și cu fiecare modificare verificată înainte să intre pe ramura principală. Pentru un proiect care trebuie să livreze același API în trei limbaje (Kotlin, Swift, TypeScript), automatizarea e esențială pentru menținerea unui API consistent în timp.
§03

Ce stă pe umerii unui om

Aceasta e secțiunea cea mai importantă a paginii.
  • Decizii de arhitectură și suprafață API publică. Cum arată tipurile, ce câmpuri se expun, cum se structurează erorile, ce e public versus internal - toate sunt decizii umane.
  • Verificarea corectitudinii față de specificații. ICAO 9303 (pentru passive auth, PACE, BAC), eIDAS (pentru niveluri de semnătură), formatele PAdES - toate sunt citite cap-coadă de un om și verificate cu testele dedicate.
  • Comportamentul applet-urilor de semnare. CEI-ul are două applet-uri principale (eDATA pentru identitate, signing pentru semnătura PAdES). Comportamentul lor real față de specificația documentată - verificat manual contra unui CEI fizic la fiecare release. Niciun model AI nu testează un card real.
  • Review-ul de securitate. Înainte de fiecare release. Codul criptografic critic (PACE, Chip Authentication, semnare) e citit linie cu linie, comparat cu specificația, executat contra vectorilor de test cunoscuți.
  • Decizii de release și versiuni. Ce intră în 0.1.x versus ce așteaptă 0.2, când se face lockstep release pentru schimbări de API, ce se merge în CHANGELOG - sunt decizii umane care țin angajamentul „frozen public API for 0.x” credibil.
§04

Cum verificăm

Procesul concret, în patru etape:
  1. Testare contra CEI fizice. Fiecare release e testat manual cu carduri reale înainte să fie publicat. Citire, verificare, semnare - întregul flux end-to-end.
  2. Verificare PAdES contra validatoare terțe. Semnăturile produse sunt deschise în Adobe Acrobat, verificate contra CSCA-ului DGP. Validatori independenți, nu doar testele noastre.
  3. Local-dev loopback contra aplicației consumatoare. Înainte de orice publicare pe Maven / Pods / npm, SDK-ul e linked local în aplicația mobilă AmSemnat și testat împotriva fluxului real de semnare.
  4. Pre-publish smoke test. Ultimul pas înainte de tag-uri și publicare. Aplicația consumatoare e compilată și rulată cu artifact-ul exact care va merge în registru. Acest pas a prins regresiuni reale care altfel ar fi ajuns la utilizatori.
§05

Limitări pe care le recunoaștem

Codul produs cu asistență AI poate avea erori subtile, mai ales în criptografie. De exemplu - o constantă ușor greșită într-o derivare de cheie, un parametru de padding inversat, o ordonare a hash-urilor mutată. Sunt erorile pe care un compilator nu le prinde și care apar doar la teste reale.

De aceea zonele critice criptografic - PACE, Chip Authentication, semnătura PAdES - au teste dedicate cu vectori cunoscuți și review uman pentru fiecare modificare. Nu ne ascundem după AI dacă apare un bug. Dacă găsești unul, deschide un issue pe GitHub și îl rezolvăm pe ramura principală cât de repede putem.

§06

De ce nu suntem certificați eIDAS QTSP

Suntem un set de instrumente. Semnăturile PAdES sunt generate cu cheia ta. Nu emitem certificate și nu operăm o autoritate de certificare. Statutul de QTSP (Qualified Trust Service Provider) cerut de eIDAS pentru semnături electronice calificate (QES) presupune audit, asigurări, infrastructură supravegheată - un set de obligații care n-au sens pentru un toolkit open-source.

Pentru flux complet QES, ai nevoie de un emitent autorizat - certSIGN, Trans Sped, Alfasign etc. Suntem aval de ei, nu un substitut. Pentru AdES (semnătură electronică avansată, recunoscută legal pentru majoritatea cazurilor), AmSemnat împreună cu certificatul de pe CEI-ul tău e suficient.

§Vezi codul

Tot ce am descris e public.

Cele trei SDK-uri Android, iOS și Expo. CHANGELOG cu fiecare release. Tagurile semantice 0.x. Fiecare se poate verifica direct.