Skip to content
VeriSwarm
Über uns
DokumentationPreiseAgentenfähigkeit
AnmeldenRegistrieren
  1. Startseite
  2. /Healthcare
  3. /Hipaa compliant ai agents
VeriSwarm
  • English
  • Español
  • ✓ Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Produkt

  • Preise
  • Dokumentation
  • API
  • Agentenfähigkeit
  • OATS-Spezifikation

Vertrauen

  • Vertrauenszentrum
  • Sicherheit
  • Compliance
  • Status
  • Änderungsprotokoll

Unternehmen

  • Über uns
  • Blog
  • Open Source
  • Investoren
  • Presse

Rechtliches

  • AGB
  • Datenschutz
  • SLA
  • DPA
  • Barrierefreiheit
Für Verantwortliche in Datenschutz, Compliance und BISO-Rollen, die Agenten mit Zugriff auf PHI einsetzen.

Ein HIPAA-konformer KI-Agent beginnt
an der Tokenisierungsgrenze.

Es gibt keinen Schalter, der einen KI-Agenten HIPAA-konform macht. Was das Risiko bei einer OCR-Risikoanalyse verringert, ist die Tokenisierung von PHI, bevor sie ein LLM oder einen Tool-Aufruf erreicht, und der Nachweis, dass dies geschehen ist. VeriSwarm Guard tokenisiert PHI an der Grenze mittels Presidio-NER-Erkennung — SSNs, MRNs, Namen und andere Identifikatoren werden durch typisierte Tokens ersetzt, bevor das Modell oder das nachgelagerte Tool jemals den Rohwert sieht — und Vault verkettet jedes Tokenisierungsereignis zu einem manipulationssicheren Journal. Beides sind Max-Plan-Funktionen. Keines von beiden zertifiziert für sich allein die Konformität; siehe was dies nicht leistet weiter unten.

Kostenlos starten — Trust Scoring inklusiveDie vollständige OCR-Prioritätenkarte ansehen

Warum PHI schwerer zu kontrollieren ist, sobald ein Agent im Spiel ist

Eine klinische Fachkraft, die Daten in ein EHR eingibt, ist ein bekannter, auditierbarer Akteur innerhalb eines Systems, das Sie bereits kontrollieren. Ein KI-Agent, der denselben Workflow abwickelt, leitet PHI durch Stellen, die ein Mensch nie durchlaufen würde: die Inferenz-API eines LLM-Anbieters, einen Drittanbieter-Tool-Aufruf, das Anfrageprotokoll einer Integration, eine Debugging-Trace. Jeder Sprung ist eine neue Stelle, an der PHI austreten kann, und die meisten davon liegen außerhalb der Zugriffskontrollen, die eine klassische HIPAA-Risikoanalyse abdecken sollte.

  • PHI, eingebettet in einen Prompt, der an ein Allzweck-LLM gesendet wird, das nicht unter einem BAA vertraglich gebunden ist.
  • Ein Patientenidentifikator, der unverändert über einen Tool-Aufruf an eine Terminplanungs-, Abrechnungs- oder CRM-Integration weitergegeben wird.
  • Rohes PHI, das in Anfrageprotokollen oder im Konversationsspeicher fortbesteht und die Interaktion überdauert, die es erzeugt hat.
  • Ein Agent, der einen fehlgeschlagenen Aufruf eskaliert oder wiederholt und dabei PHI an einen Fallback-Anbieter sendet, den niemand geprüft hat.

Für nichts davon braucht es einen menschlichen Innentäter oder einen externen Angreifer. Es passiert einfach, wenn ein Agent genau das tut, was ihm aufgetragen wurde — in einer Geschwindigkeit und einem Umfang, die eine manuelle Prüfung unmöglich machen.

PHI an der Grenze tokenisieren

Guards PII-Tokenisierung läuft, bevor der Text die Grenze verlässt — bevor er ein LLM erreicht, bevor er einen Tool-Aufruf erreicht. Die Presidio-NER-Erkennung durchsucht ausgehenden Text nach PHI-artigen Werten und ersetzt jeden davon durch ein typisiertes, sitzungsgebundenes Token. Das Modell und das nachgelagerte Tool bekommen jemals nur das Token zu sehen.

POST /v1/suite/guard/pii/tokenize
{
  "text": "Patient SSN 555-12-3456, MRN 88213, call at 917-555-0199",
  "ttl_seconds": 3600
}

→ {
  "tokenized_text": "Patient SSN [VS:SSN:a1b2c3], MRN [VS:ID:d4e5f6],
                      call at [VS:PHONE:g7h8i9]",
  "session_id": "sess_...",
  "tokens_created": 3
}

Tokens werden nur über einen separaten Rehydrate-Aufruf auf ihre Originalwerte zurückgeführt, gebunden an dieselbe Sitzung, und nur wenn eine nachgelagerte Schreiboperation den echten Wert tatsächlich benötigt — etwa ein Terminplanungssystem, das eine reale Telefonnummer wählen muss. Jede Rehydrierung ist selbst ein Ereignis, das der Mandant auditieren kann.

Der Audit-Trail, den eine Risikoanalyse wirklich verlangt

Das Durchsetzungsmuster der HHS OCR im Jahr 2026 hat eine durchgängige Grundursache: das Versäumnis, eine genaue und gründliche Risikoanalyse durchzuführen — mit weitem Abstand die größte Kategorie von Durchsetzungsmaßnahmen gegenüber allen anderen Ursachen zusammen. Eine Risikoanalyse ist nur so belastbar wie die sie stützenden Nachweise — und ein editierbares Protokoll ist ein schwacher Nachweis.

Vault verkettet jedes Tokenisierungsereignis, jede Rehydrierung und jede Agentenentscheidung mit einem SHA-256-Verweis auf den Vorgänger. Ein Verifizierungsaufruf durchläuft die gesamte Kette und meldet genau, wo sie bricht, falls sie bricht:

GET /v1/suite/vault/verify

→ {
  "ok": true,
  "events_verified": 41_902,
  "first_event_id": "evt_...",
  "last_event_id":  "evt_...",
  "errors": []
}

Ein mandantenscoped PHI-Inventar (GET /v1/suite/guard/phi-inventory) aggregiert dieselben Tokenisierungssignale zu einem Bericht nach PHI-Typ, nach Agent und nach HIPAA-artiger Sensitivitätsstufe — und beantwortet damit die Frage, die eine Risikoanalyse zuerst beantworten muss: Wo fließt PHI tatsächlich durch die Agentenflotte.

Was dies nicht leistet

Klarheit über die Grenze ist hier wichtiger als der Verkaufspitch. PHI-Tokenisierung und Vaults Audit-Journal sind keine HIPAA-Compliance-Zertifizierung, keine Rechtsauskunft und kein Ersatz für eine formale Risikoanalyse. Ihre Aktivierung macht eine Covered Entity oder einen Business Associate nicht HIPAA-konform. HIPAA verlangt weiterhin eine Risikoanalyse, die Ihre Agenten tatsächlich berücksichtigt, das vollständige Set technischer Sicherheitsmaßnahmen der Security Rule (Verschlüsselung, Zugriffskontrolle, Integrität, Übertragungssicherheit), eine Business Associate Agreement mit jeder Partei im Datenpfad — einschließlich des Modellanbieters — sowie Richtlinien und Schulungen, die außerhalb jeder Software existieren.

VeriSwarm schließt eine spezifische, wirkungsstarke Lücke: PHI, das untokenisiert ein LLM oder einen Tool-Aufruf erreicht, und ein Audit-Protokoll, das nicht beweisen kann, dass es nachträglich nicht bearbeitet wurde. Alles andere in einem HIPAA-Compliance-Programm — Scope, BAAs, Incident Response, Mitarbeiterschulung — muss weiterhin vom Team aufgebaut werden, das die Agenten einsetzt, mit Rechtsberatung bei allem, was eine formale Einreichung oder einen Corrective Action Plan berührt.

Häufig gestellte Fragen

Was macht einen KI-Agenten „HIPAA-konform"?

Es gibt keine HIPAA-Compliance-Zertifizierung, die ein Anbieter Ihnen ausstellen kann, und kein Softwaremerkmal, das eine Covered Entity oder einen Business Associate allein konform macht. Was ein HIPAA-konformer KI-Agenten-Workflow braucht, ist eine Risikoanalyse, die den Agenten tatsächlich berücksichtigt, PHI, das gemäß den technischen Sicherheitsmaßnahmen der Security Rule behandelt wird (Zugriffskontrolle, Audit-Kontrollen, Integrität, Übertragungssicherheit), und eine Business Associate Agreement mit jedem, der in Ihrem Auftrag PHI berührt — einschließlich des Modellanbieters. VeriSwarms Rolle ist enger gefasst und konkret: PHI tokenisieren, bevor sie ein LLM oder einen Tool-Aufruf erreicht, und die Audit-Nachweise erzeugen, die eine Risikoanalyse und eine HIPAA-Audit-Kontrollanforderung tatsächlich verlangen.

Erfüllt die Tokenisierung von PHI vor einem LLM-Aufruf die HIPAA Security Rule?

Tokenisierung unterstützt direkt zwei technische Sicherheitsmaßnahmen der Security Rule: Zugriffskontrolle (PHI erreicht nie ein System — einschließlich eines Drittanbieter-LLM —, das sie nicht sehen sollte) und Audit-Kontrollen (§164.312(b) verlangt Hardware-, Software- oder Verfahrensmechanismen, die Aktivität in Systemen mit ePHI aufzeichnen und untersuchen). Sie erfüllt für sich allein nicht das vollständige Set technischer Sicherheitsmaßnahmen — Verschlüsselung bei Übertragung und Speicherung, Integritätskontrollen, Übertragungssicherheit und eine unterzeichnete BAA mit jeder Partei im Datenpfad müssen weiterhin unabhängig davon vorhanden sein.

Wie tokenisiert VeriSwarm PHI in den Tool-Aufrufen eines Agenten?

Guards PII-Tokenisierungs-Endpunkt (POST /v1/suite/guard/pii/tokenize) führt Presidio-NER-Erkennung über ausgehenden Text aus und ersetzt erkannte Werte — SSNs, MRNs, Namen, Telefonnummern, Adressen — durch typisierte Tokens wie [VS:SSN:a1b2c3], gebunden an eine Sitzung mit konfigurierbarem TTL (Standard 1 Stunde, maximal 24). Der tokenisierte Text ist das, was das LLM oder das nachgelagerte Tool erreicht. Ein separater Rehydrate-Aufruf stellt Originalwerte nur wieder her, wenn eine Schreiboperation sie tatsächlich benötigt, und jede Rehydrierung ist selbst ein auditierbares Ereignis.

Was geschieht mit dem Audit-Trail, nachdem PHI tokenisiert wurde?

Wenn Vault aktiviert ist, wird jedes Tokenisierungs- und Rehydrierungsereignis in ein hashverkettetes Journal geschrieben — jedes Ereignis verknüpft sich mit dem Hash seines Vorgängers, sodass jede rückwirkende Änderung die Kette sichtbar bricht. GET /v1/suite/vault/verify durchläuft die gesamte Kette und liefert ok: true/false mit dem exakten Ereignis, an dem die Verifizierung fehlschlägt, falls sie fehlschlägt. Das ist das Artefakt, gegen das eine Risikoanalyse oder eine OCR-Audit-Kontrollprüfung abgeglichen werden kann, statt einem nicht verifizierbaren Protokoll zu vertrauen.

Ist PHI-Tokenisierung im kostenlosen Plan verfügbar?

Nein. PHI-Tokenisierung ist Teil von Guard, und das unveränderliche Audit-Journal ist Vault — beides sind Max-Plan-Funktionen (299 $/Monat), nicht in Gates kostenloser Stufe enthalten. Gates kostenlose Stufe deckt Agenten-Trust-Scoring, Ereigniserfassung und Entscheidungsprüfungen ab; PHI-Handling und der hashverkettete Nachweispfad erfordern Max.

Entfällt durch die Nutzung von VeriSwarm die Notwendigkeit einer Business Associate Agreement?

Nein. Eine BAA ist ein rechtliches Instrument zwischen einer Covered Entity und jedem, der in ihrem Auftrag PHI erstellt, empfängt, aufbewahrt oder überträgt — diese Anforderung entfällt nicht dadurch, dass eine technische Kontrolle das Risiko verringert. Wenn die Tool-Aufrufe Ihres Agenten, der LLM-Anbieter oder die Infrastruktur PHI berühren, benötigen diese Beziehungen weiterhin BAAs, ob mit oder ohne Tokenisierung.

Weiterführende Lektüre

Wenn die OCR bereits eine Prüfung eröffnet oder einen Corrective Action Plan angefordert hat, sieht das Nachweispaket anders aus als bei einer präventiven Risikoanalyse — siehe OCR-Risikoanalyse-Durchsetzung und KI-Agenten. Für die vollständige Zuordnung der OCR-Durchsetzungsprioritäten 2026 zu VeriSwarm-Funktionen starten Sie bei VeriSwarm für das Gesundheitswesen.

Sehen Sie PHI-Tokenisierung an Ihrem eigenen Agentenverkehr

Eine 30-minütige Live-Demo an Ihrer eigenen Flotte — keine Demodaten. Guard und Vault sind Max-Plan-Funktionen; Trust Scoring selbst ist kostenlos.

Kostenloses Konto erstellenDie OCR-Prioritätenkarte lesen