Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / Drata HIPAA Compliance: PHI Safeguards in 2026

Drata HIPAA Compliance: PHI Safeguards in 2026

Risk analysis failures sit behind 76% of HIPAA enforcement actions in 2025, according to The HIPAA Journal’s annual breach report. That single statistic explains why healthcare organizations and their business associates are rethinking how they manage HIPAA. Its no longer enough to conduct an annual policy review, it is now a continuous control problem.

Drata fits that shift. It is a security and compliance automation platform that connects to the systems where PHI lives, maps controls to the HIPAA Privacy, Security, and Breach Notification Rules, and keeps evidence current between formal assessments.

This guide covers what Drata actually does for HIPAA: which rules it addresses, how the automation works in practice, what it leaves to humans, and how readiness compares to running parallel frameworks like SOC 2.

Drata HIPAA Compliance - How the Platform Operationalizes PHI Safeguards in 2026

What Is HIPAA and Why Does Compliance Matter?

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is the U.S. federal law governing the protection of protected health information (PHI). It applies to two categories of organizations: covered entities (health plans, healthcare clearinghouses, and most providers) and business associates, a category that captures any vendor, SaaS company, or service provider that creates, receives, maintains, or transmits PHI on behalf of a covered entity.

Enforcement is led by the HHS Office for Civil Rights (OCR). Penalties scale with culpability, capped at roughly $2.1 million per violation category per year after inflation adjustments. OCR’s 2025 enforcement priorities were almost entirely focused on the Security Rule, particularly the requirement to conduct a thorough, organization-wide risk analysis. The agency has confirmed that 2026 will follow the same playbook, with risk management evidence (proof that identified risks are being actively reduced) becoming a separate focus area in its own right.

Healthcare also remains the most expensive sector for breaches. IBM’s 2024 Cost of a Data Breach Report put the average healthcare breach at $9.48 million, more than double the cross-industry average. The cost is not abstract: in 2025, OCR penalties for risk analysis failures ranged from $25,000 against small practices up to $3 million against a national medical supplier following a phishing-driven breach.

What Is Drata and How Does It Support HIPAA Compliance?

Drata is a GRC automation platform that integrates with cloud infrastructure, identity providers, HRIS systems, ticketing tools, and endpoint management to continuously collect evidence and test controls against more than 30 compliance frameworks. HIPAA was added in late 2021 as Drata’s third framework, joining SOC 2 and ISO 27001.

For HIPAA specifically, Drata does not certify anyone; there is no formal HIPAA certification anyway, but it operationalizes the work that OCR expects to see when an investigation lands. That includes mapped controls for administrative, physical, and technical safeguards; policy templates for HIPAA-specific requirements like the Business Associate Agreement; embedded workforce training; an integrated risk management module; and an evidence library that auditors and counsel can access during a review.

Worth Knowing: There is no government-issued HIPAA certification.

Any vendor claiming to make you "HIPAA certified" is using marketing language. What auditors and OCR investigators actually look for is documented, ongoing compliance with the three HIPAA Rules. Drata's value sits in producing that documentation continuously rather than retroactively. For a deeper look at what formal certification actually involves in adjacent frameworks, see our guide to HIPAA certification.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Key HIPAA Requirements Drata Helps You Address

HIPAA consists of three operative rules, each with distinct compliance obligations. Drata’s control library maps to all three.

HIPAA Privacy Rule

The Privacy Rule governs the use and disclosure of PHI in any form: electronic, paper, or verbal. It defines 18 specific identifiers that constitute PHI, sets the minimum necessary standard, and gives patients rights of access, amendment, and accounting of disclosures.

Drata supports this through policy templates (notice of privacy practices, minimum necessary use, patient rights procedures), access tracking through integrations with identity providers, and workforce training that covers permissible uses and disclosures.

HIPAA Security Rule

The Security Rule is where most enforcement activity happens. It applies specifically to electronic PHI (ePHI) and requires three categories of safeguards: administrative, physical, and technical. According to HHS, the Security Rule “requires implementation of appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic protected health information.” Drata’s control library maps directly to the 45 CFR Part 164 implementation specifications, both required and addressable.

HIPAA Breach Notification Rule

The Breach Notification Rule requires notification to affected individuals, HHS, and, for breaches affecting 500 or more residents of a state, the media, no later than 60 days after discovery. Drata supports breach response through incident management workflows, policy templates that codify the four-factor risk assessment, and audit trails for breach documentation. The platform does not file your OCR breach report for you; that remains a human task, but it keeps the underlying evidence organized.

Important: OCR has explicitly stated that breach notification failures were the second most common reason for a financial penalty in 2025. More than one-fifth of enforcement actions included a breach notification violation. The 60-day clock starts at discovery, not at confirmation, so detection latency directly increases legal exposure.

How Drata Automates HIPAA Compliance

Automation in Drata operates on four layers: evidence collection, control monitoring, gap detection, and integration with healthcare-relevant tools. The combination is what produces the continuous compliance posture that OCR is now effectively demanding through its risk management initiative.

Automated Evidence Collection for HIPAA Audits

Drata reports that its platform automates roughly 80% of evidence collection across frameworks. For HIPAA, that means pulling configuration data from AWS, Azure, or GCP; enrollment status from MDM tools like Jamf or Intune; SSO and MFA enforcement from Okta or Entra ID; and onboarding/offboarding records from HRIS platforms. Instead of screenshotting these on demand for an auditor, the platform timestamps and stores them on a continuous basis.

Real-Time HIPAA Compliance Monitoring

The platform runs automated tests against connected systems daily. If MFA is disabled on an administrator account that has access to a system holding ePHI, the relevant control flips to failing status and the owner gets notified. This is the difference between point-in-time compliance and continuous compliance: you find out about drift within hours, not at next year’s audit.

Continuous Control Testing and Gap Detection

Drata uses AI to surface why a control is failing rather than simply flagging that it has failed. For HIPAA, this matters because the Security Rule includes both “required” and “addressable” implementation specifications, and “addressable” does not mean optional. Gap detection that explains the underlying issue helps teams document why a particular safeguard was implemented, modified, or substituted with an equivalent measure, which is exactly what 45 CFR §164.306(d) requires. For organizations newer to this process, a structured gap analysis is often the best place to start.

Healthcare-Specific Integrations

Drata integrates with more than 300 systems. For healthcare and HIPAA workflows, the most relevant categories are cloud providers (where ePHI is stored), identity and access management tools (which enforce technical safeguards), endpoint and MDM platforms (which prove device-level encryption), HRIS systems (which drive workforce training and offboarding evidence), and ticketing tools (which provide audit trails for access changes).

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

HIPAA Compliance Checklist in Drata

A HIPAA program in Drata generally breaks into four blocks of work, aligned with how the Security Rule is structured.

Administrative Safeguards

Administrative safeguards cover policies, procedures, and the conduct of the workforce. Drata supports the risk analysis requirement, the single most-enforced provision in 2025, along with security management process documentation, workforce security policies, information access management, training records, contingency planning, and periodic evaluation. The risk analysis module is where most teams will spend the bulk of their setup time, and rightly so given OCR’s current enforcement posture.

Physical Safeguards

Physical safeguards address facility access controls, workstation use and security, and device and media controls. For SaaS-native business associates, much of this is inherited from cloud providers, AWS SOC 2 reports, for example, and Drata’s vendor management module captures that inheritance. For organizations with their own facilities, controls and evidence need to be tracked manually, with Drata acting as the system of record.

Technical Safeguards

Access control, audit controls, integrity controls, person or entity authentication, and transmission security. This is where Drata’s integrations do the most work. Encryption at rest and in transit, MFA enforcement, role-based access, audit logging, and session timeouts can all be evidenced automatically through connected cloud and identity systems.

Organizational Requirements and Policies

This is the Business Associate Agreement (BAA) layer. Drata provides a BAA template and tracks BAA status across vendors that touch PHI on your behalf. The platform also supports the documentation requirements at 45 CFR §164.316, which mandates that all policies, procedures, and required actions are maintained in writing for six years from creation or last effective date.

Pro Tip: When you set up your HIPAA framework in Drata, configure it alongside SOC 2 from day one if both are on your roadmap. Drata reports up to 81% control overlap between the two, and shared control mapping means a single piece of evidence satisfies multiple framework requirements simultaneously. Setting them up separately later means duplicating work you have already done.

HIPAA Risk Assessments with Drata

Risk analysis is the most consequential HIPAA requirement to get right. Of the ten resolution agreements OCR announced in the first five months of 2025, every single one included a finding that the organization had not conducted a compliant risk analysis. Penalties for this single failure ranged from $25,000 to $3 million.

How Drata Supports Risk Assessment and Mitigation

Drata’s risk management module guides teams through identifying assets that store or process ePHI, scoring threats and vulnerabilities, and documenting mitigation owners and timelines. Crucially, it links each identified risk to the specific controls and evidence intended to mitigate it. When a control fails, the linked risk’s posture updates automatically. This is precisely what OCR’s expanded 2026 enforcement focus on risk management, not just risk analysis, is asking organizations to demonstrate.

Mapping Risks to HIPAA Controls in Drata

Each risk in Drata can be mapped to one or more HIPAA controls, and each control is mapped back to specific implementation specifications in 45 CFR Part 164. The result is a defensible chain: identified risk → assigned control → automated evidence → audit-ready documentation. This chain is what counsel will reach for first if OCR opens an investigation following a breach.

HIPAA Training Management in Drata

HIPAA requires workforce training, and OCR has cited training gaps as a contributing factor in multiple recent settlements. Drata addresses this through embedded training content and tracked completion, not just a checkbox.

Annual HIPAA Training Tracking

Drata’s embedded HIPAA training tracks completion at the individual workforce member level, surfaces overdue users, and timestamps every completion event for audit purposes. When OCR asks for training records, this is the artifact that answers the question.

Embedded and Custom Training Workflows

Beyond the built-in modules, organizations can upload their own training content, covering role-specific PHI handling, for example, and assign it through Drata. This is particularly useful for organizations that already have an LMS but want compliance tracking centralized in one place rather than scattered across systems.

Audit Trails for Workforce Compliance

Drata generates a workforce training register with dates, content versions, and acknowledgements. This is one of the artifacts OCR investigators routinely request, and having it on demand significantly reduces the scramble that typically precedes external reviews.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Getting Audit-Ready for HIPAA with Drata

There is no formal HIPAA audit in the way SOC 2 or ISO 27001 have audits. What exists is OCR investigation (triggered by complaints or breaches), HIPAA readiness assessments performed by external firms, and the practical reality that customers and partners increasingly demand attestations of HIPAA compliance as a condition of doing business.

How to Configure Drata for HIPAA Readiness

Initial configuration involves selecting HIPAA as a framework, connecting integrations covering all systems that store or process ePHI, customizing the HIPAA-specific policy templates (including the BAA template), assigning control owners, and running the risk analysis module against a complete asset inventory. Most organizations complete initial configuration in 4 to 12 weeks depending on environment complexity.

Evidence Collection and Audit Documentation

Once configured, Drata acts as the single repository for HIPAA evidence: control statuses, policy versions, training completions, risk registers, vendor BAAs, and access reviews. The platform produces auditor-ready exports that can be shared directly with external assessors or counsel, eliminating the document-request back-and-forth that typically adds weeks to an assessment timeline.

Working with a HIPAA Auditor or CPA Firm

Drata supports auditor workspaces where assessors get scoped access to relevant evidence without seeing the broader environment. For organizations pursuing third-party HIPAA attestations or HITRUST CSF certification, which incorporates HIPAA requirements, this collaboration model substantially reduces the friction of traditional document requests.

Insider Note: OCR investigations average 57 months from complaint or breach notice to enforcement action, according to a 2025 review of recent settlements by law firm Shook, Hardy & Bacon. That is nearly five years. The implication: evidence retention matters enormously. Continuous evidence collection through a platform like Drata is materially easier to defend than reconstructed evidence pulled together after an investigation lands.

Drata HIPAA vs. Other Compliance Frameworks

Most organizations that need HIPAA also need SOC 2, and increasingly ISO 27001 or HITRUST as well. Drata’s design assumption is that controls and evidence should be reused across frameworks rather than duplicated, and the efficiency gains compound quickly once you have more than one framework active.

HIPAA and SOC 2: Different End States, Substantial Overlap

HIPAA is a legal obligation enforced by a federal regulator. SOC 2 is a voluntary attestation that demonstrates security posture to customers and prospects. They are not the same thing, but they share significant ground, particularly around access control, encryption, audit logging, and incident response. For a detailed breakdown of how these two frameworks compare structurally, our ISO 27001 vs SOC 2 guide covers the key architectural differences that also inform how HIPAA fits into the picture.

Running Multiple Frameworks Simultaneously

When multiple frameworks are active in Drata, a single control like “MFA is enforced on all administrative accounts” satisfies SOC 2 CC6.1, ISO 27001 A.9.4.2, and HIPAA §164.312(d) at once. One piece of evidence, three framework requirements. This is the single most important reason organizations consolidate on a GRC platform: the multiplier effect on previously duplicated work compounds quickly as your compliance obligations grow. If you are evaluating which automation platform fits your stack, our Drata vs Vanta comparison walks through how the two leading tools differ in practice.

Does Drata support HIPAA compliance?

Yes. HIPAA was added as Drata’s third framework in late 2021 and is one of more than 30 frameworks the platform supports. Coverage includes the Privacy Rule, Security Rule, and Breach Notification Rule, with mapped controls, policy templates, embedded training, and a BAA template.

Drata maintains its own security and compliance posture, including SOC 2 attestation and signed BAAs with customers who need them. Because Drata may process customer-uploaded evidence that contains references to PHI, signing a BAA with Drata is standard practice for healthcare customers and should be treated as a day-one task.

Drata automates evidence collection for most technical safeguards, access control, encryption, audit logging, transmission security, and parts of administrative safeguards, including workforce training records, access reviews, and contingency plan documentation. Physical safeguards in cloud-native environments are often inherited from cloud provider attestations and managed through vendor management workflows.

No, and it is not designed to. HIPAA requires a designated security officer and privacy officer under 45 CFR §164.308 and §164.530. Drata is the operational tooling that those officers use to do their job effectively. The platform reduces administrative load substantially, but accountability for HIPAA compliance still sits with named individuals inside the organization.

Initial readiness typically takes 4 to 12 weeks for a SaaS company or business associate with a modern cloud stack. Larger or more complex environments may take 3 to 6 months. The variable is not Drata; it is how much foundational work, policies, risk analysis, training, BAA inventory, the organization needs to do for the first time. Organizations already compliant with SOC 2 or ISO 27001 in Drata can typically achieve HIPAA readiness substantially faster because of the control overlap.

Yes. Drata signs BAAs with customers when its handling of customer data could touch PHI. Healthcare organizations and business associates should request and execute a BAA with Drata as part of onboarding. The presence of a signed BAA is itself an audit artifact and should be stored in Drata’s vendor management module alongside all other third-party BAAs.

Evidence is collected automatically through integrations, timestamped, and stored centrally. Drata retains evidence consistent with HIPAA’s six-year documentation requirement under 45 CFR §164.316(b)(2). Auditors and assessors can be granted scoped workspace access without exposing the broader environment, and exports are available for any required external review.

OCR’s enforcement priorities have not been subtle: do the risk analysis, manage the risks you find, and document everything in a way that survives a multi-year investigation timeline. Drata is built for that pattern of work. If you want to understand how it fits your specific environment, whether you are a covered entity, a business associate, or a healthcare technology company scaling into enterprise contracts, talk to an expert who can map the right framework strategy to where you actually are.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

SOC 2 and ISO 27001 Engagement

After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information

The EU AI Act’s transparency requirements take effect on 2 August 2026, and most of the companies they cover still think the rules are not their problem. Article 50 applies to any business that publishes AI-generated content or runs an AI system that talks to people in the EU. That includes the marketing team generating campaign images and the support team running a chatbot. It also covers the AI agents you’ve wired into customer email. Penalties reach €15 million or 3% of total worldwide annual turnover, whichever is higher, and you don’t need an office in Europe to be in scope. If your content or your chatbot reaches EU users, the obligations reach you. In a nutshell: if you publish AI-generated images or video, deploy chatbots or AI agents that interact with EU users, or publish AI-written text on matters of public interest, then yes, the EU AI Act applies, starting 2 August 2026. A quick word on the “AI Act delay” headlines. The Digital Omnibus package did push the high-risk system deadlines back, in some cases by more than a year, but it did not move the deployer obligations in Article 50. Companies that read those headlines and stood down their AI Act work made an expensive mistake, because the rules most likely to touch an ordinary business are the ones that stayed on the calendar. What Article 50 Actually Requires Article 50 of the AI Act sets out transparency obligations in four situations. In plain English: Tell people when they’re talking to AI. Systems designed to interact directly with people — chatbots, voice assistants, and AI agents — must make clear that the user is dealing with AI, unless that’s already obvious. Mark AI-generated content so machines can detect it. Providers of generative AI systems must mark outputs in a machine-readable format, typically through metadata and watermarking, so the content is detectable as artificially generated. Label deepfakes. Anyone deploying AI to generate or manipulate image, audio, or video content that resembles real people, places, objects, or events, and could falsely appear authentic, must disclose that the content is artificial. Label AI-generated text on matters of public interest. Text published to inform the public must carry a label if AI-generated or manipulated, unless a human reviewed it and a person or organization holds editorial responsibility for it. Article 50 also covers emotion recognition and biometric categorization systems, which carry their own disclosure duties. Far fewer businesses run into those, so this article sticks to the four above. The distinction running through all of this is provider vs deployer. The provider builds or supplies the AI system. The deployer uses it professionally. Most companies reading this are deployers. If You Use AI-Generated Images Realistic AI images sit closer to the deepfake rules than most marketing teams assume. The Act’s definition covers content depicting people, objects, places, and events that could falsely appear authentic to a viewer, which describes a large share of what image generators produce for campaigns, social posts, and landing pages. So what does “clearly and distinguishably labeled” mean? The threshold is best described by its failures: a tiny disclosure hidden in the website footer doesn’t qualify. Neither does a faint label on an image, a label that flashes for an instant in a video, or a disclosure buried in your terms and conditions. The label has to be visible right where someone sees the content, and it has to meet accessibility standards so people with disabilities can perceive it too. The Code of Practice proposes a standardized “AI” visual label, localized per language (“KI” in German, “IA” in French). It also draws a useful line between fully AI-generated content and AI-assisted content, with lighter requirements for the latter. A designer who used AI to extend a background is in a different position from a team publishing a fully synthetic image of a person who doesn’t exist. Important: The deepfake duty doesn’t care about intent. A flattering, harmless AI image of your CEO at an event that never happened is still a deepfake under the Act. Marketing teams generate this kind of content casually. From August, every one of those images needs a label. If You Deploy AI Agents or Chatbots The rule itself is simple: people must know they’re dealing with AI. The provider carries the design obligation, but as the deployer you’re the one putting the system in front of your customers, and you’re the one an EU regulator will contact if your branded assistant pretends to be human. The Act contains an exception for cases where it’s “obvious” the user is talking to AI, judged from the perspective of a reasonably well-informed and observant person. Don’t lean on it. What’s obvious to your product team isn’t obvious to every customer, and the human-sounding voice agents and email-writing AI agents rolling out right now are designed specifically to not feel like software. If an AI agent negotiates a renewal over email or handles a support ticket end to end, disclose it. Pro Tip: Put the Disclosure at the Start of the Interaction Put the disclosure at the start of the interaction, in the interface itself: “You’re chatting with an AI assistant.” A line in your privacy policy doesn’t meet the standard, and a disclosure that appears after the conversation ends is worthless. For voice agents, say it up front in the greeting. What Your AI Vendors Owe You The machine-readable marking obligation in Article 50(2) sits with providers — the companies supplying your generative AI tools. The final Code of Practice expects providers to apply at least two layers of marking where necessary, such as embedded metadata combined with watermarking, and to offer detection mechanisms so deployers, authorities, and researchers can verify whether a piece of content came from AI. One timing caveat: the Digital Omnibus gives generative AI systems already on the market before 2 August 2026 until 2 December 2026 to comply with the marking requirement. Every other Article 50 obligation stays on

How Axipro Guided Technovative Solutions & DigiProd Pass to ISO 27001