How to Train AI Models Legally Under GDPR
Most companies training AI models get the legal basis wrong before they write a single line of code. They assume they need consent, panic when they realize collecting consent from millions of scraped web sources is impossible, and either give up on the project or proceed without any basis at all. Neither is necessary. Legitimate interest, not consent, is the basis most AI developers actually rely on under Article 6, and it works, provided you can show the balancing test in writing.
That balancing test is where most DPIAs for AI training fall apart. Regulators want to see the reasoning behind the claim, why the interest is legitimate, why the processing is necessary, and why it doesn’t override the rights of the people whose data you scraped. Without that documentation on file, legitimate interest collapses the moment a regulator asks a question.
Getting the legal basis right is the easy part. The harder problem shows up later, once the model is already trained and someone asks you to delete their data, and you discover that unlearning a person from a set of trained weights isn’t something you can actually do on demand.
Legal basis for training AI models on personal data
Article 6 of the GDPR gives you six possible legal bases, and for training data collected at scale, only one of them realistically works. Legitimate interest, under Article 6(1)(f), is what nearly every AI developer training on scraped or first party data ends up relying on, and this isn’t a workaround. The European Data Protection Board confirmed it directly in Opinion 28/2024, issued in December 2024 in response to a request from the Irish Data Protection Commission. The opinion stated that legitimate interest can serve as a valid basis for both training and deploying AI models, provided the developer runs a proper assessment and puts real safeguards in place. That confirmation is critical because before it, developers were operating on inference and hope. Now there’s a documented EU-level position to point to.
What legitimate interest is not is a free pass. The EDPB’s opinion came with conditions attached, and regulators in Italy, France, and Ireland have each shown they’re willing to investigate companies that treat legitimate interest as a formality rather than a genuine test. The basis holds up when you can show your reasoning. It collapses when you can’t.
Documenting a Legitimate Interest Assessment for training data
Legitimate interest only works if you can show your work, and the EDPB opinion sets out a three-step test that regulators now expect to see documented before training starts, not reconstructed after a complaint. The first step is identifying the actual interest being pursued, and it has to be specific and real, not a vague reference to innovation. The second step is necessity, showing that the processing is actually required to achieve that interest and that a less invasive method wouldn’t work as well. The third step is the balancing test itself: weighing your interests against the rights and reasonable expectations of data subjects, and this is where most DPIAs fall short.
A defensible balancing test accounts for whether the data subject would reasonably expect their data to end up in a training set, what safeguards reduce the impact on them, and whether they’ve been given a way to object. Safeguards that regulators have pointed to in practice include filtering out sensitive content before training, pseudonymizing where feasible, and limiting how much personal data a model can output on request. Skip this documentation, and you’re not relying on legitimate interest; you’re hoping nobody asks.
Why consent doesn’t work for AI training data
Consent looks like the obvious choice until you try to apply it to a dataset built from billions of scraped web pages. GDPR requires consent to be freely given, specific, informed, and unambiguous, and none of those conditions survives contact with a training pipeline that pulls text and images from millions of sources with no direct relationship to the people in that data. You cannot get informed consent from someone whose blog post from 2014 ended up in a training corpus. You don’t know who they are, you have no contact method, and even if you did, asking millions of individuals to opt in before training begins would make large-scale model development impossible.
This is exactly the gap legitimate interest was built to fill. GDPR has always recognized that consent is unworkable in situations without a direct relationship between controller and data subject, and AI training is close to the clearest example of that scenario the regulation has faced. The EDPB’s opinion acknowledges this directly, which is part of why it landed on legitimate interest rather than trying to force consent into a context it was never designed for.
Special category data in AI training datasets
Legitimate interest does not extend to special category data. Health information, biometric data, political opinions, sexual orientation, and the other categories listed in Article 9 need their own exemption before they can be processed at all, and Article 9 does not currently include one written for AI training. This creates a real problem for anyone scraping the open web, because special category data shows up in training corpora constantly, in social media posts, forum discussions, and public profiles, whether or not anyone intended to include it.
The European Commission proposed closing this gap through the Digital Omnibus package, which would have added a new Article 9(2) exemption covering AI training under strict safeguards. That proposal has not become law. As of mid-2026, the relevant provisions were dropped from the Council’s negotiating text after member states failed to reach agreement, which means the exemption doesn’t exist yet and may not arrive in its proposed form. Until that changes, the practical answer is filtering special category data out of training sets before processing begins, or relying on one of the existing Article 9(2) exemptions, such as data the individual has manifestly made public themselves, where it genuinely applies.
The right to object to AI training
Article 21 gives anyone the right to object to processing based on legitimate interest, and for AI training this right has become one of the main mechanisms regulators expect to see in practice. Meta’s attempt to train its AI models on public posts from EU users triggered exactly this dynamic. After a wave of complaints, including from the privacy group noyb, Meta paused the plan, then relaunched it with an opt-out window and clearer notice before training began. That sequence is now close to the template regulators expect other companies to follow.
An opt-out has to be genuinely accessible, not a setting buried three menus deep, and it has to be offered before processing starts wherever that’s practically possible. Companies that gave people a real chance to object, with clear notice and enough lead time to act on it, have been the ones able to defend continued reliance on legitimate interest when challenged. Companies that treated the objection right as a formality to satisfy after the fact have not fared as well.
Scraping public web data for AI training under GDPR
A profile being visible to anyone with an internet connection has nothing to do with whether GDPR applies to it. This is the single most common misunderstanding among teams building AI training pipelines, and regulators have spent the last two years closing that gap through enforcement. The Dutch data protection authority stated it plainly in its 2024 guidance, describing scraping personal data as almost always a violation of GDPR, and backed that position with a €30.5 million fine against Clearview AI for scraping over 30 billion images from public sites including LinkedIn and Facebook. The Italian Garante fined the same company €20 million on the same underlying facts, and the UK Information Commissioner’s Office followed with a £7.5 million penalty later upheld on appeal by the Upper Tribunal in October 2025, which confirmed that a company scraping European faces from outside Europe still falls within the regulation’s reach.
None of these cases turned on whether the data was technically public. They turned on the absence of a documented legal basis, the absence of transparency toward the people whose data was collected, and, in Clearview’s case, the absence of any Article 9 exemption for biometric data that GDPR treats as a special category regardless of where it was found. The EDPB formalized this position in July 2026 with Guidelines 03/2026 on web scraping for generative AI, its first framework built specifically around this question. According to the guidelines, publishing something online is not consent to scrape it, and that consent as a legal basis is effectively unworkable for large-scale collection. Legitimate interest remains the route that survives contact with a regulator, and only when the three-part test behind it has actually been documented.
Robots.txt and terms of service in web scraping
Robots.txt was never a law, and ignoring it does not by itself create GDPR liability. What changed in 2026 is that regulators started treating it as evidence. The EDPB’s Guidelines 03/2026 name robots.txt, ai.txt files, CAPTCHAs, and login walls directly, describing them as signals relevant to a person’s reasonable expectations about their data, which is one of the core factors in the legitimate interest balancing test. Scraping a site that has explicitly blocked AI crawlers through ai.txt does not automatically breach GDPR, but it makes the argument that people expected their data to be left alone considerably harder to lose, and that argument is exactly what your balancing test needs to win.
Platform terms of service work on a separate track, contract law rather than data protection law, but the two tracks increasingly point in the same direction. Ignoring a platform’s terms while scraping personal data tends to accompany the same failures regulators penalize under GDPR: no transparency, no minimization, no path for people to object. Treat technical signals and platform terms as inputs to your legitimate interest documentation rather than obstacles to route around. A scraping operation that respects robots.txt, throttles its request rate, and can show why it proceeded where terms were ambiguous is in a materially stronger position than one that has no record of considering any of it.
Synthetic data and personal data risk
Training on synthetic data instead of real personal data reduces your GDPR exposure, though it does not eliminate it. The regulation’s test has never been about how a dataset was generated. It is about whether a person can be identified from it, and synthetic data can fail that test in ways that are easy to miss during development. Models used to generate synthetic records can memorize and reproduce fragments of the real data they were trained on, and researchers have repeatedly shown that supposedly de-identified or synthetic datasets can be reverse-engineered when enough auxiliary information is available. A synthetic dataset that statistically mirrors a small population, a rare medical condition, or a distinctive combination of attributes can still point back to specific individuals even though no real record appears in the output.
On its opinion on AI models, the EDPB notes that synthetic-looking outputs can still fall under GDPR if they carry identifiable traits from real people or were generated from training data that was never properly anonymized in the first place. The practical implication is that synthetic data needs the same anonymization rigoUr as any other privacy technique, tested against the standard in Recital 26, which asks whether reidentification is reasonably likely by any method available to anyone, not just the method you tested against. Treat synthetic data as a risk reduction tool that still requires a documented assessment, not a compliance shortcut that lets you skip one.
Scraping pseudonymized data vs anonymized data
These two terms get used interchangeably in casual conversation about AI training data, and the difference between them determines whether GDPR applies to your dataset at all. Pseudonymized data usually has direct identifiers removed or replaced, names swapped for tokens, email addresses hashed, but the underlying individual can still be identified if someone gains access to the key or combines the dataset with other available information. GDPR states that pseudonymized data remains personal data, fully subject to the regulation, because the possibility of reidentification still exists even if you have no intention of exercising it.
Anonymized data is different in kind, not degree. For data to fall outside GDPR entirely under Recital 26, reidentification has to be effectively impossible by any method reasonably likely to be used, evaluated against the current state of technology and the resources someone might realistically bring to bear. That bar is considerably higher than most teams assume when they describe their training data as anonymized after running a straightforward tokenization pass. If a determined party with access to auxiliary datasets, sufficiently powerful re-identification tools, or knowledge of the pseudonymization method could plausibly reverse it, you are working with pseudonymized data wearing anonymized language, and GDPR still applies in full.
Informing data subjects their data trained your model
Scraping data from a third-party website instead of collecting it from the person yourself does not remove your transparency obligations; it just moves you from Article 13 to Article 14. Article 13 covers data collected directly from the individual. Article 14 covers everything else, which includes essentially all AI training data pulled from the open web, and it requires the same core disclosures, including what data you’re processing, why, under what legal basis, and how long you’re keeping it, delivered within a reasonable period after collection.
Most AI developers reach for the disproportionate effort exception in Article 14(5)(b), assuming that scraping billions of records from millions of people makes individual notice obviously impossible. However, according to newly adopted EDPB Guidelines 03/2026, this exception is read narrowly, tying it to the purposes Recital 62 actually lists, such as archiving, scientific research, and statistics, none of which commercial model training falls under cleanly. Regulators expect a genuine case-by-case balancing exercise weighing the number of people affected, the age of the data, and the safeguards already in place, applied to the dataset as a whole rather than checked against every record. If you invoke the exception routinely without that documented balancing, you would’ve built a compliance gap that looks exactly like the ones Clearview and other scraping operators have already been fined for.
What a workable transparency notice actually looks like
Even where the disproportionate effort exception genuinely applies, and the EDPB guidelines state that it should be the exception rather than the default, you are not excused from transparency altogether. What replaces individual notice is a public disclosure, and regulators have started specifying what that disclosure needs to contain rather than leaving it to interpretation. The categories of personal data processed, the purposes and legal basis relied on, and retention periods are baseline requirements. What has changed with the latest guidelines is the expectation around sources – the EDPB now expects as complete a list of scraped sources as practically possible, ideally with domain names and collection dates presented in a searchable format rather than a general statement that the internet was the source.
A notice that satisfies this standard reads more like a data inventory than a privacy policy summary. It names the categories of sites and platforms scraped, gives a collection date range, states plainly that legitimate interest under Article 6(1)(f) is the basis relied on, and includes a functioning mechanism for people to object or request exclusion, ideally one that works before their data is collected rather than only after.
Regulators reviewing complaints under the new guidelines are positioned to treat generic notices as the same failure that got Clearview and OpenAI’s Italian subsidiary fined for transparency violations under Article 5(1)(a).
Cross-border transfers of AI training data
If your training pipeline moves EU personal data to servers or teams outside the EEA, you need a transfer mechanism on top of everything else, and this is where AI training projects run into a genuinely unstable piece of the legal landscape right now. Most US-based AI developers rely on the EU-US Data Privacy Framework, the adequacy decision the European Commission adopted in July 2023, which lets certified US companies receive EU personal data without Standard Contractual Clauses or a separate transfer impact assessment for each transfer. That framework survived its first legal challenge at the EU General Court in September 2025 and remains valid law as of this writing.
It is not settled law. A more serious challenge is pending before the Court of Justice of the EU, and in July 2026 the EDPB itself asked the European Commission to reassess the framework after a US Supreme Court ruling affecting the Federal Trade Commission’s independence, since that independence was one of the safeguards the original adequacy decision relied on. None of this has invalidated the framework yet, and companies certified under it can still lawfully receive EU data today. But building a training pipeline that assumes the Data Privacy Framework will still exist in its current form a year from now is a real risk, not a hypothetical one. The companies that came through the Schrems II invalidation of Privacy Shield with the least disruption in 2020 were the ones that already had Standard Contractual Clauses and transfer impact assessments in place as a backup rather than a dependency on adequacy alone. Given where the legal challenge to the current framework stands, that same approach, keeping SCCs ready as a fallback for any US-based training infrastructure, is the defensible position going into the next year, not an overcautious one.
How to delete personal data from a trained AI model
Once personal data has been used to train a model, deleting that specific person’s contribution from the finished weights is not something current technology can reliably do. A trained neural network does not store information the way a database does, with each person’s data sitting in an identifiable row you can locate and remove. It stores statistical patterns distributed across billions of parameters, shaped jointly by every example in the training set. Isolating and reversing the influence of one person’s data from that structure, without retraining the model from scratch, remains one of the genuinely unsolved problems in machine learning research. This is something European data authorities have acknowledged, describing what a model has learned as something that cannot, at the current state of the art, be easily unlearned.
This creates a real compliance gap that no amount of policy language closes. Article 17 gives individuals the right to erasure, and the GDPR does not carve out an exception for AI models because the technology is hard. Regulators have been explicit that the difficulty of compliance does not remove the obligation, it just means the obligation has to be met through different mechanisms than a simple database delete, and those mechanisms need to be in place before training happens rather than invented after someone files a request.
Removing personal data before training begins
Since removing a person’s influence from finished weights is unreliable, the practical answer to erasure requests is preventing the problem at the collection and preprocessing stage rather than trying to solve it after the model exists. This is the mitigation the guidelines actually point toward. Maintaining an exclusion list of people who have objected or requested removal, and checking that list before each training run rather than after, keeps a deletion request from ever becoming an unlearning problem. The same applies to filtering out sensitive sources and categories of data at the ingestion stage, since data that never enters the training set never needs to be removed from it.
This shifts erasure compliance from a reactive process to an operational one. A company running periodic model updates or retraining cycles can fold deletion requests received since the last training run directly into the next one, at the cost of a somewhat longer preprocessing pipeline rather than a technically impossible extraction task. Companies that treat their training pipeline as a one-time event and only think about erasure when the first request lands are the ones that end up with no good options. However, the ones that build request tracking and exclusion filtering into every training cycle from the start are the ones that can actually demonstrate compliance when a regulator asks.
What machine unlearning actually does
Machine unlearning refers to techniques that attempt to remove specific data’s influence from an already trained model without a full retrain, and the field has moved fast enough that it deserves a place in your compliance strategy, just not as a guaranteed fix. Methods like SISA training, which partitions training data into shards so a shard can be retrained in isolation when needed, and influence function-based approaches that estimate and subtract a data point’s effect on the model, can reduce the cost of removing specific data considerably compared to a full retrain from zero.
None of these methods currently offer a verified guarantee that the targeted data’s influence has been fully removed, and researchers have documented a pattern called catastrophic unlearning, where model performance degrades sharply, sometimes exponentially, as more data points are removed through these techniques. There is also no settled industry consensus on how to measure whether unlearning actually succeeded, which is a serious problem if a regulator later asks you to demonstrate that a person’s data no longer influences the model’s outputs. Use unlearning techniques where they’re mature enough to apply; membership-style deletions in smaller fine-tuned models are the strongest current use case, but do not represent partial or approximate unlearning to a regulator as equivalent to erasure, because the audit trail behind that claim will not currently hold up.
When to retrain a model instead of unlearning
There is a threshold past which patching a model through unlearning or exclusion costs more, in engineering time and residual legal risk, than simply retraining it on a cleaned dataset, and knowing where that threshold sits for your own pipeline matters more than treating either option as a default. A small number of individual erasure requests can usually be absorbed by an exclusion list feeding into your next scheduled training cycle. A pattern of requests concentrated in a specific data source, a successful audit finding that a model regurgitates identifiable personal information from a particular category of training data, or a regulator ordering deletion following an enforcement action are all signals that incremental fixes are no longer defensible.
At that point, a full retrain on a filtered dataset is not just the safer legal position – it is usually the more reliable technical one, since it avoids stacking unverified unlearning operations on top of each other and produces a model whose training data composition you can actually document and defend. Building retraining cost into your model lifecycle planning from the start, rather than treating it as an emergency response, is what separates companies that can absorb an enforcement order without shutting down a product from ones that cannot.
Privacy-enhancing technologies for GDPR-compliant AI training
Differential privacy, federated learning, and homomorphic encryption all get pitched as ways to sidestep GDPR entirely, and none of them actually do that on their own. What they do is reduce the risk profile of a training pipeline, which matters directly for the legitimate interest balancing test covered earlier, but reducing risk is a different thing from making personal data stop being personal data. The EDPB’s Guidelines on anonymisation, adopted at the same July 2026 plenary session as the web scraping guidance, states that a technique only removes GDPR’s application when reidentification becomes genuinely impossible by any method reasonably likely to be used, not just resistant to the specific attack you tested against.
This distinction has real consequences for how these technologies show up in your documentation. A privacy-enhancing technology used well is evidence in your DPIA; it strengthens your necessity and proportionality argument and can tip a borderline legitimate interest case in your favor. What it is not is a substitute for the DPIA itself, or a reason to skip the transparency and legal basis work covered in the earlier sections of this article. Treat these tools as risk mitigation layered onto a compliant pipeline, not as an alternative to building one.
Differential privacy in model training
Differential privacy works by injecting calibrated statistical noise into the training process, so the model’s output changes negligibly whether or not any single individual’s data was included in the training set. The practical effect is that an attacker running a membership inference attack, trying to determine whether a specific person’s data was used to train the model, gets a mathematically bounded ability to succeed, controlled by a parameter typically called epsilon that lets you trade off privacy strength against model accuracy.
Regulators have started treating this as a concrete expectation rather than an optional enhancement. The Guidelines recommend that organizations processing data for AI training either apply differential privacy mechanisms during training or document specifically why the dataset’s characteristics make that unnecessary, which shifts the default toward using it rather than justifying its absence only when challenged. The tradeoff you’re managing is real – tighter privacy budgets degrade model utility, and tuning epsilon to a level that satisfies both your engineering requirements and a defensible privacy justification takes actual testing, not a default value copied from a paper.
Federated learning and data minimization
Federated learning trains a shared model across multiple parties, hospitals, banks, or business units, without any raw data ever leaving its original location. Each party trains locally on its own data and shares only model updates, gradients or weight adjustments, which get aggregated centrally into an improved shared model. For organizations that need to train on data spread across separate legal entities or jurisdictions, this architecture can meaningfully reduce the scope of what counts as a cross-border transfer, since the personal data itself stays put.
It does not eliminate GDPR’s application to that data, and it does not eliminate the privacy risk on its own. The model updates shared during federated training can leak information about the underlying data through what researchers call gradient leakage, where an adversary reconstructs approximations of the original training examples from the shared gradients. This is why federated learning in production privacy-sensitive deployments, healthcare consortia in particular, is typically paired with differential privacy or secure aggregation rather than deployed alone. Federated learning changes where processing happens and narrows your transfer exposure. It does not by itself satisfy Article 5’s security and minimization requirements without additional safeguards layered on top.
Homomorphic encryption for training data
Homomorphic encryption allows computation to run directly on encrypted data, producing an encrypted result that decrypts to the same answer you’d get from running the computation on the unencrypted original. For AI training, this means a model could theoretically be trained without the data ever being decrypted at any point in the pipeline, which is about as strong a technical privacy guarantee as currently exists.
The barrier is computational cost, and it remains severe enough that full homomorphic encryption is not a realistic option for most large scale AI training today. Recent benchmarking on medical imaging models found training times of over ten hours under full homomorphic encryption compared to under an hour without it, and that gap widens further as model size increases. Selective and hybrid approaches, applying encryption only to the most sensitive layers or combining lighter encryption with differential privacy, have cut that overhead by as much as ninety per cent in recent research, and that’s the direction the field is moving. For now, homomorphic encryption is realistic for smaller-scale or highly sensitive training tasks where the cost is justified, cross-institutional collaboration on health data being the clearest current example, but it isn’t yet a tool you can apply to a full-scale foundation model training run without accepting a computational cost most organizations can’t absorb.
GDPR documentation required before training an AI model
Every team I’ve seen get AI training compliance right converges on the same three documents, and every team that gets caught out is usually missing at least one of them. The Data Protection Impact Assessment under Article 35 is the centrepiece, mandatory for AI training given the scale and novelty of the risk involved, and it’s the document a regulator asks for first when investigating a complaint. The Record of Processing Activities under Article 30 is the second, and it needs a dedicated entry for the training pipeline itself rather than being folded into a general AI systems line. The third is the Legitimate Interest Assessment – the three-step test covered earlier in this article – which technically lives inside the DPIA but gets treated as effectively its own artefact by regulators because it’s the piece they scrutinize hardest.
Miss any of these, and you’re short on the evidence that makes legitimate interest defensible in the first place. Regulators have been clear that missing DPIAs are one of the fastest-growing enforcement categories, and an organization with no RoPA entry, no DPIA, and no documented legal basis review is starting an investigation from zero rather than from a position where good faith effort can mitigate the outcome.
What a DPIA for AI training must include
A DPIA template built for a customer database or a marketing analytics tool leaves real gaps when applied to AI training, because it was never built to answer the questions that actually matter for a model. The EDPB’s WP248 guidelines set the baseline structure, but AI training introduces at least four elements a pre-AI template won’t prompt you to address. You need to describe the model type and architecture in enough detail to show whether you’re dealing with a predictable supervised system or a large language model whose outputs are inherently harder to anticipate, since that distinction shapes how a regulator assesses risk. You need to document training data sources down to origin, collection date, and preprocessing steps, and if personal data entered the pipeline, you need to be specific about how.
Where the model is a third-party foundation model you’ve fine-tuned rather than something built from scratch, both the base model’s data provenance and your fine-tuning dataset need separate treatment, because a regulator will ask about both layers. And the assessment needs to function as a living document rather than a one-time filing, since a model that continues learning through fine-tuning or online updates can drift from the behavior your original DPIA assessed, which means the DPIA needs a review trigger tied to material changes in the pipeline.
Mapping the AI pipeline in your RoPA
A RoPA built around traditional data flows describes where data comes from and where it goes. For AI training, that’s necessary but incomplete, because the processing itself has stages a simple flow diagram doesn’t capture. Your entry needs to separate data collection or scraping, preprocessing and filtering, the training run itself, fine-tuning if it happens as a distinct later stage, and deployment, because each of those stages can involve different legal bases, different retention periods, and in some cases different data controllers entirely.
This granularity matters practically when a regulator investigates, because dual role situations are common in AI development. A company that both trains its own base model and fine-tunes a third-party foundation model is a controller for one processing activity and potentially a processor or joint controller for another, and a RoPA that treats all AI processing as a single undifferentiated line item cannot show that distinction. Retention also needs separate documentation for each artefact your pipeline produces; the source training data, the training logs, and the model weights themselves each carry their own retention justification, and treating them as one undifferentiated blob is one of the more common gaps auditors flag in 2026 reviews.
Compliance risk inherited from foundation models
Fine-tuning a foundation model does not give you a clean slate. If the base model was trained on personal data collected without a valid legal basis, that underlying problem does not disappear because your own fine-tuning process was compliant – it just moves one layer down, where it’s harder to see and easier to overlook. Your DPIA for a fine-tuned model needs to document the base model’s provenance, not just your own dataset, and that means asking the foundation model provider directly what legal basis they relied on and what categories of personal data their training corpus contained.
This is exactly the gap that AI DPA clauses have started addressing directly, with vendor contracts now commonly including representations that a provider’s foundation model was not trained on unlawfully processed personal data, backed by liquidated damages if that representation turns out to be false. If your vendor cannot produce that kind of documentation on request, you’re inheriting an unquantified risk into your own compliance posture, and a regulator investigating your fine-tuned model will not treat ignorance of the base model’s training data as a defence. Ask before you build on top of a foundation model, not after a request or complaint forces the question.
Conclusion
Training AI models under GDPR really comes down to one habit – know your legal basis, write it down, and give people a real way to object. Everything else in this article is detail sitting on top of that. The rules will keep shifting a bit as new guidance lands, but the companies that stay out of trouble aren’t the ones with the cleverest workarounds. They’re the ones who did the paperwork before anyone asked for it.