KI-Agenten und eIDAS: QES-Integration für Verträge

TL;DR

Ein KI-Agent sollte eine Signaturtransaktion vorbereiten und weiterleiten, aber niemals die signierende Person imitieren. Unter eIDAS gehört eine qualifizierte elektronische Signatur einer natürlichen Person und wirkt EU-weit wie eine handschriftliche Unterschrift. Ein elektronisches Siegel ist das getrennte Werkzeug, um Herkunft und Integrität eines Dokuments einer juristischen Person nachzuweisen, auch bei kontrollierter Automatisierung. Eine sichere Integration friert das finale Artefakt ein, berechnet serverseitig seinen Digest, zeigt einer berechtigten Person das exakte Dokument und die geschäftliche Wirkung, holt eine einmalige Freigabe über einen qualifizierten Vertrauensdiensteanbieter oder eine Wallet ein, validiert die zurückgegebene Signatur gegen EU-Vertrauenslisten und löst erst danach die Folgewirkung aus. Behandle ein Login mit ID Austria oder EUDI Wallet als Authentifizierung, nicht als Zustimmung zu einem Vertrag. Kapsle OIDC-, CSC- und Signaturaufrufe hinter einem Adapter, mache Callbacks idempotent, binde jede Freigabe an Digest, Signer, Zweck, Policy-Version und Ablaufzeit und bewahre das signierte Artefakt samt Prüfbericht auf. Kaufe den qualifizierten Vertrauensdienst und baue Orchestrierung, Policy und Evidenzschicht selbst.

Ein KI-Agent kann einen Vertrag entwerfen und einen Signaturflow starten. Als qualifiziert elektronisch signierende Person solltest du ihn nicht modellieren. Das robuste Production-Muster ist ein Two-Phase Commit: Der Agent schlägt ein unveränderliches Artefakt vor, ein Policy Service entscheidet über die Freigabe, eine berechtigte Person prüft den exakten Payload und das System validiert die Signatur, bevor Vertrag, Zahlung oder Account-Status final werden.

Dieser Guide richtet sich an Product-, Engineering-, Security- und Procurement-Teams. Er trennt Login, Zustimmung, QES, elektronisches Siegel und Audit Logs. Er ist ein technischer und kommerzieller Leitfaden, keine Rechtsberatung. Für Selective Disclosure, SD-JWT VC, mdoc und Zero Knowledge dient unser Production-Guide zu Zero-Knowledge Proofs. Hier geht es um die Bindung einer echten Entscheidung an das Dokument des Agenten.

Du willst verifizierbare Freigaben in einen Agent-Workflow einbauen?

Signaturarchitektur scopen

Darf ein KI-Agent in der EU einen Vertrag unterschreiben?

Behandle den Agenten nicht als menschlichen QES-Signer. Eine qualifizierte elektronische Signatur wird von einer natürlichen Person erstellt und hat laut Artikel 25 der konsolidierten eIDAS-Verordnung die gleiche Rechtswirkung wie eine handschriftliche Unterschrift. Der Agent darf Daten vorbereiten, einen Digest berechnen und eine Freigabe anfordern. Die ausdrückliche Autorisierung der Person bleibt die Trust Boundary.

EUDI Wallets müssen natürlichen Personen QES standardmäßig ermöglichen. Die kostenlose Nutzung darf auf nicht berufliche Zwecke begrenzt werden. Ein Business-Workflow braucht daher weiterhin einen Plan für Signaturdienst, Enrolment und Validierung. Den Rahmen setzt die Verordnung (EU) 2024/1183.

Für juristische Personen gibt es das elektronische Siegel. Die eSignature FAQ der Europäischen Kommission trennt die Signatur einer natürlichen Person vom Siegel einer juristischen Person. Ein qualifiziertes Siegel stützt Herkunft und Integrität. Es drückt nicht automatisch die Zustimmung eines menschlichen Vertreters aus. Automatisiertes Siegeln braucht interne Berechtigungskontrollen.

ID Austria, Handy-Signatur, EUDI Wallet und QES sind keine Synonyme

Capability	Nachweis	Einsatz
ID Austria oder EUDI Login	Eine Person hat sich elektronisch authentifiziert.	Baue die User Session auf. Werte den Login-Callback nicht als Vertragsfreigabe.
QES	Eine natürliche Person hat die exakten Daten qualifiziert signiert.	Nutze sie für einen geprüften, unveränderlichen Payload, wenn Rechts- und Risikoanalyse QES wählen.
Qualifiziertes eSeal	Herkunft und Integrität eines Dokuments einer juristischen Person.	Nutze es für kontrollierte Unternehmensausgabe. Authority und Release Policy bleiben außerhalb des Agenten.
Agent Audit Record	Was Modell, Tools, Policy Engine und Menschen getan haben.	Operative Evidenz, aber kein Ersatz für QES, Siegel oder Identität.

Handy-Signatur ist ein Legacy-Begriff. Die aktuelle Hilfe zu ID Austria erklärt, dass ID Austria sie abgelöst hat und Login sowie qualifiziertes Signieren unterstützt. Es bleiben getrennte Aktionen. Die offizielle OpenID-Connect-Dokumentation beschreibt Authentifizierung. Ein OIDC-Response bindet den User nicht an Version 7 eines Liefervertrags.

Referenzarchitektur: vorschlagen, freigeben, validieren, ausführen

Agent schlägt vor. Das Modell erzeugt Vertragsdaten und Entwurf. Es darf weder Signer wählen noch die Approval Policy lockern.
Anwendung friert ein. Rendere das finale Artefakt, speichere es unveränderlich und berechne den Digest serverseitig. Jede Änderung erzeugt eine neue Freigabe.
Policy autorisiert. Löse Person, Organisation, Vollmacht, Limits, Vertragsklasse und Vier-Augen-Regel aktuell auf. Fehlt Authority, brich geschlossen ab.
Mensch prüft. Zeige Dokument, Gegenpartei, Betrag, Laufzeit, irreversible Folgen und Version. Eine Agent-Zusammenfassung allein reicht nicht.
QTSP oder Wallet signiert. Nutze eine einmalige Anfrage mit kurzer Gültigkeit und gebundenem Return State.
Verifier prüft. Prüfe Bytes, Zertifikatsqualifikation, Trust Chain, Revocation, Zeit, Format, Digest und Signer. Ein Success Webhook ist keine Validierung.
Anwendung führt einmal aus. Nutze eine idempotente Outbox. Doppelte Callbacks erzeugen keine zweite Wirkung.
Archiv erhält Evidenz. Bewahre Artefakt, Prüfbericht, Entwurf, Vollmachtssnapshot, Policy-Version, Approval Event, Provider IDs und Agent Trace auf.

Das EUDI Wallet eSignature Manual beschreibt Wallet- und QTSP-getriebene QES Journeys. In beiden prüft und genehmigt der User, während eine qualifizierte Einheit die Signatur erstellt. Die Wallet gehört an die Autorisierungsgrenze, nicht in den Tool Loop.

Provider-neutraler Signing Request

{
  "idempotency_key": "contract:847:version:7",
  "artifact_sha256": "8c4f...",
  "artifact_version": 7,
  "intended_signer": "person_219",
  "represented_organisation": "org_44",
  "purpose": "Liefervertrag Version 7 annehmen",
  "signature_level": "QES",
  "policy_version": "contract-signing/12",
  "expires_at": "2026-08-13T15:30:00Z"
}

Nutze DRAFT -> FROZEN -> AWAITING_APPROVAL -> SIGNING -> VALIDATING -> EFFECTIVE plus REJECTED, EXPIRED und FAILED. Nur der Verifier darf EFFECTIVE setzen. Das EUDI Architecture and Reference Framework 1.5.1 definiert ein Remote Signing Interface. Halte dein Domain Model stabil und kapsle die bewegliche Interoperabilität im Adapter.

Die EUDI Reference Implementations enthalten mobile rQES Libraries, CSC-API-Komponenten und eine RP-zentrierte Signing Application. Sie beschleunigen Tests, ersetzen aber weder Provider-Qualifizierung noch Threat Model und Validierung.

Risiken, die die Signatur allein nicht löst

Prompt Injection nach Freigabe: Friere Bytes ein und binde den Request an ihren Digest.
Falscher Signer: Löse Vollmacht zur Ausführungszeit aus einer vertrauenswürdigen Quelle auf.
Summary statt Vertrag: Zeige das vollständige Artefakt und die materiellen Folgen.
Replay: Nutze Nonce, Ablaufzeit, Idempotency Key, Provider Event ID und Compare-and-Set.
Falsches Success Signal: Validiere die Signatur unabhängig vor der Geschäftswirkung.
Approval Fatigue: Eskaliere nur irreversible oder policy-getriggerte Aktionen und zeige Diffs.

Validierung darf nicht auf einer beim Launch kopierten Zertifikatsliste beruhen. Österreichs Regulator erklärt, wie die beaufsichtigte Vertrauensliste an das System der Mitgliedstaaten anschließt. Nutze gepflegte EU-Trusted-List-Verarbeitung und bewahre die Evidenz zum Signaturzeitpunkt auf.

Build vs Buy: Kaufe den Trust Service, baue die Control Plane

Baue QTSP, Certificate Authority oder Qualified Signature Creation Device nicht als normales Feature selbst. Kaufe den qualifizierten Vertrauensdienst. Baue Vertragsversionierung, Agentenberechtigungen, Vollmachtsauflösung, Approval UX, Policy Evaluation, idempotente Ausführung, Evidenz und Reporting.

Prüfe Länder und Identity-Methoden, PAdES/XAdES/CAdES/ASiC, One-Shot und wiederverwendbare Credentials, Remote QES, Web- und App-Handoff, signierte replay-sichere Webhooks, Validation Report, Revocation und Timestamping, Recovery-Flows, professionelle Kosten und die spätere EUDI-Wallet-Fähigkeit des Adapters. Miss Kosten pro wirksamer Vereinbarung, nicht pro API Call. Die KI-Agent-SLA-Vorlage macht Completion, Approval, Validierung und Audit-Evidenz messbar.

QES macht ein KI-System nicht automatisch compliant

Eine gültige Signatur beweist ein definiertes Trust-Service-Ergebnis. Sie beweist weder Modellgenauigkeit noch Vertretungsmacht, Fairness, rechtmäßige Datennutzung oder sektorale Compliance. Wo die Hochrisiko-Pflichten des EU AI Act gelten, behandeln Artikel 12 und 14 Logging und Human Oversight. QES ist eine Kontrolle, kein Compliance Shortcut.

Authentication beantwortet, wer da ist. Authorization beantwortet, was diese Person tun darf. Signature beantwortet, welche Daten sie genehmigt hat. Validation beantwortet, ob das Trust-Ergebnis gültig ist. Execution beantwortet, ob die Wirkung genau einmal eintrat. Ein einziges approved-Boolean kann diese Grenzen nicht tragen.

"Der Agent schreibt den Vorschlag. Die Person genehmigt den unveränderlichen Payload. Der Verifier prüft die Signatur. Die Anwendung führt genau einmal aus. Vier Owner machen die Trust Boundary sichtbar."

FAQ zu KI-Agenten und eIDAS-Signaturen

Kann ein KI-Agent eine QES erstellen?

Behandle den Agenten nicht als QES-Signer. Eine natürliche Person prüft und genehmigt den exakten Payload im qualifizierten Signaturprozess. Der Agent darf Dokument und Workflow vorbereiten.

Ist ein ID-Austria-Login eine Vertragsunterschrift?

Nein. ID Austria unterstützt Login und qualifiziertes Signieren als getrennte Aktionen. OIDC baut die Session auf. Die Signatur braucht eine eigene, an das Dokument gebundene Transaktion.

Hat ID Austria die Handy-Signatur ersetzt?

Ja. Verwende in neuen Produkttexten und Integrationen den aktuellen Namen ID Austria. Handy-Signatur bleibt nur als verständlicher Migrationsbegriff sinnvoll.

Was unterscheidet QES und eSeal?

QES ist die Signatur einer natürlichen Person und wirkt EU-weit wie eine handschriftliche Unterschrift. Ein qualifiziertes eSeal gehört einer juristischen Person und stützt Herkunft sowie Integrität, nicht menschliche Zustimmung.

Wie bindest du Human Approval an den Vertrag?

Friere die Bytes ein, hashe serverseitig, zeige das vollständige Artefakt und binde eine einmalige Anfrage an Digest, Signer, Zweck, Policy-Version und Ablauf. Validiere vor der Ausführung.

Soll ein Team den eIDAS-Signaturdienst selbst bauen?

Meistens nicht. Kaufe den qualifizierten Vertrauensdienst und baue Domain Controls, Policy, UX, Validierung, Idempotenz, Evidenz und Monitoring selbst.

Fazit

Eine sichere AI-Signing-Architektur ist absichtlich unspektakulär. Der Agent entwirft. Die Anwendung friert ein und hasht. Policy löst Authority auf. Eine Person genehmigt im qualifizierten Flow. Der Verifier prüft gegen aktuelle Trust-Evidenz. Erst dann wird die idempotente Transaktion wirksam.

Halte Login, Signatur, Siegel, Validierung und Ausführung getrennt. Kaufe den qualifizierten Vertrauensdienst und investiere Engineering in die Control Plane, die die echte Geschäftsverpflichtung schützt.

Recherchequellen

Recherchiert und geprüft am 13. August 2026. Prüfe die aktuelle Quelle und hole für die konkrete Transaktion Rechtsberatung ein.