Subscribe now

For the last couple of years, AI companies have been very careful to include a warning whenever their tools answer questions about law, taxes, medicine, or anything else that could end up in a courtroom.

The warning usually says something like: “This tool does not provide legal advice.”

Unfortunately, it often appears immediately after the AI has just written three paragraphs explaining what you should probably do about your legal problem. Which is how we ended up here.

A new lawsuit claims that an AI chatbot provided legal guidance that allegedly caused real harm. According to the complaint, a user relied on responses from ChatGPT suggesting they could challenge a legal settlement and file certain motions. The plaintiff argues that following that guidance violated the settlement agreement and caused financial damage.

Whether the claim ultimately succeeds is almost beside the point. The interesting part is that courts are now being asked to answer a question that didn’t exist five years ago:

If someone relies on advice generated by an AI system, who’s responsible?

The “It’s Just a Tool” Argument

AI companies tend to describe their systems as tools. Search engines, calculators, productivity software; helpful things that produce information but don’t make decisions.

That description makes sense technically, but from a user’s perspective, the experience feels different. Ask a chatbot a legal question and the response often reads like something written by a junior associate who stayed up too late preparing for a meeting.

It explains the issue.

It walks through possible options.

Sometimes it even sounds confident about what the next step should be.

At that point the line between “information” and “advice” gets fuzzy.

Courts Have Had a Preview

Lawyers got an early warning in 2023 when two attorneys filed a brief citing several cases that did not exist. ChatGPT had confidently invented them. The court sanctioned the lawyers, who discovered the hard way that judges expect attorneys to confirm their sources.

That episode was embarrassing, but the responsibility was easy to assign: the lawyers filed the brief.

The new lawsuits are different. Now plaintiffs are asking whether the software itself created the problem. That moves the conversation into a different legal territory entirely.

Product Liability Is the Next Logical Stop

One theory being explored is simple: if a product generates guidance that people reasonably rely on, and that guidance causes harm, the manufacturer might bear some responsibility.

The argument sounds familiar because courts have dealt with similar questions before.

• Medical devices that provide faulty readings.

• Financial tools that produce misleading calculations.

• Navigation systems that send drivers somewhere dangerous.

In each case the legal system eventually asks whether the product was designed in a way that created an unreasonable risk. The lawsuits against AI companies are starting to ask the same question.

Disclaimers Are Not Magic Shields

Developers understandably point to the warnings that appear on nearly every AI interface: “not legal advice,” “consult a professional,” and similar language. Those disclaimers help. Courts do consider them.

But disclaimers are rarely the end of the analysis. Judges tend to look at the entire product experience. If the system produces authoritative-sounding explanations that look like professional advice, a warning label may not completely resolve the issue.

Think about a GPS app that warns you not to rely on its directions, and then confidently instructs you to drive into a lake. At some point the warning and the behavior stop matching.

There’s Also a Regulatory Angle

Another legal thread appearing in early discussions is unauthorized practice of law.

Several states already regulate who can give legal advice. Traditionally that meant licensed attorneys. Software companies never had to worry about it because software didn’t really “advise” anyone.

Generative AI changed that. When a chatbot analyzes a legal problem and suggests next steps, the question becomes whether the tool has crossed a line that regulators care about. That issue is still developing, but it’s already on the radar.

Design Decisions Suddenly Matter

Once liability enters the conversation, product design choices take on new significance. Developers now have to think carefully about how systems respond to questions involving legal rights or obligations.

• Should the AI decline to answer certain questions entirely?

• Should it limit responses to summaries of publicly available law?

• Should it avoid recommending specific actions?

Different companies are experimenting with different guardrails, and it’s likely those guardrails will evolve as courts weigh in.

This Goes Beyond AI Companies

You don’t need to be building AI models for this issue to affect you. Employees are already using AI tools to help with tasks that have legal implications:

• reviewing contracts

• interpreting regulations

• analyzing litigation risk

• drafting internal policies

Sometimes those outputs are excellent. Sometimes they’re confidently wrong.

When organizations begin relying on those answers, the question of responsibility becomes more complicated, and courts are only starting to sort through it.

Where This Probably Leads

Generative AI isn’t going away. It’s too useful. The legal system will eventually settle into a framework that balances innovation with accountability, the same way it has for every major technology before it.

In the meantime, lawsuits like this one will test the boundaries. Lawyers sometimes describe that stage of development as “an emerging area of law.”

A more accurate description might be: the part where everyone starts hiring litigators.

Subscribe now

Subscribe now

Some days you wake up and the world feels normal.

February 10, 2026 was not one of those days.

On that single Wednesday, two federal judges reached very different conclusions about whether legal materials involving AI are protected from discovery. The two cases (United States v. Heppner and Warner v. Gilbarco) didn’t get coffee together beforehand, yet they walked out of court with opposite takes on the big question: When is the stuff your legal team creates with AI still privileged or protected?

One judge said no protections at all for AI-created materials. The other said yes, protect them like traditional work product.

What Happened in Heppner (S.D.N.Y.)

In United States v. Heppner, the defendant was under federal indictment and subpoena. He took information from his counsel, plugged it into a publicly accessible AI tool (Anthropic’s Claude), and generated 31 documents outlining defense research and strategy. Then he shared those documents with his lawyers.

Judge Jed S. Rakoff held the resulting materials are not protected by:

• Attorney-client privilege: Claude is not a lawyer and there was no attorney-client communication through it.

• Work product doctrine: The materials were created by the defendant on his own initiative, not at counsel’s direction, and didn’t reflect counsel’s mental strategy at the time they were generated.

A key part of the court’s reasoning was that the specific AI platform’s privacy policy permitted collection, retention, and potential disclosure of user inputs and outputs, meaning Heppner could not reasonably expect confidentiality.

The judge also made an important point that still has attorneys taking multiple sips of coffee when they read it: simply sharing documents with counsel after they were created by a non-lawyer does not magically make them privileged.

Meaning old rules clearly applied: Privileged communications are between clients and attorneys with confidentiality intact. These weren’t.

But Then There’s Warner (E.D. Mich.)…Very Different Result

Meanwhile, in Warner v. Gilbarco in the Eastern District of Michigan, a judge denied a motion to compel production of materials related to the use of generative tools in litigation prep, treating them as work product under Federal Rule of Civil Procedure 26(b)(3).

Here’s the takeaway from the Michigan court’s view: When generative tools are used as part of lawyers’ litigation preparation, and those materials reflect strategy or direction from counsel, they can be treated the same way courts treat traditional work product, even if AI was involved.

The Warner judge emphasized that tools like ChatGPT are “tools” rather than persons, and using them as part of legal research or drafting doesn’t inherently waive protections, particularly when the work product has not been widely disclosed and remains part of counsel’s strategic thinking.

The Distinction

If you glance at the headlines, you might think courts are hopelessly split on “AI and privilege.”

They’re not.

Both rulings stick to classic doctrines, attorney-client privilege and work product, and don’t create new laws about technology. What differs is the context:

Who initiated the work?

In Heppner, it was the defendant on his own.

In Warner, it was in the course of litigation preparation under counsel’s direction.

Were confidentiality expectations preserved?

In Heppner, the AI platform’s own policies undermined confidentiality.

In Warner, the context was within counsel’s controlled processes.

Whose mental processes are reflected?

Material that reflects an attorney’s strategy is more likely to be protected than material generated independently by someone without counsel involvement.

That’s privilege doctrine 101, with the courtroom deciding how normal-world rules interact with tools that weren’t around when many of those doctrines were written.

What This Means for You

If you think the takeaway from these cases is “never use AI,” you’ll be deeply frustrated, and also missing what the courts are telling us.

What these rulings tell us, and this is legal-as-heck practical, is that technology choices are important because they affect fundamental legal prerequisites like confidentiality and attorney involvement.

If you want protections to stick:

1. Keep counsel in the driver’s seat. If legal materials are AI-assisted, make sure counsel directs the creation, not the client acting on their own.

2. Document the context. Material created under counsel direction and maintained confidentially is more likely to meet privilege/work product standards.

3. Watch privacy policies closely. If the AI tool’s terms allow data pooling, training, or third-party disclosure, courts may treat that as a waiver or lack of confidentiality.

4. Put policies in place. Your internal AI usage policy should require enterprise-grade tools with contractual confidentiality promises for legal work.

5. Train the users. An employee who thinks “AI is fine because I emailed it to counsel later” is going to create real discovery headaches.

In short: privilege protections aren’t gone just because AI is involved, but you’re more likely to lose them if the technology obscures the legal context in which the work was done.

Subscribe now

Subscribe now

A public company employee will go to jail and pay huge fines if they are caught trading their company’s stock with material nonpublic information (MNPI).

But if that same employee just buys an “event contract” in the prediction markets on their company’s quarterly earnings results? A gray area that seems like it may be technically legal based on current laws…

That makes total sense, right?

Employees and Prediction Markets

Every so often, a new behavior shows up in the workplace that makes lawyers stop mid-sentence and say, “Wait…people can do that now?”

Prediction markets are one of those things.

Prediction markets let people place real-money bets on real-world outcomes. Product launches. Regulatory approvals. Court decisions. Elections. Sometimes things that are being actively discussed in internal meetings earlier that same day.

For example, you can bet on all major public company earnings.

You can also bet on a variety of tech news. Below are just a few that involve OpenAI. Like “Will Sam Altman be in jail by June 30th?” 🤣

You can even bet on what words will be said on an earnings call.

Last quarter, the CEO of Coinbase pulled up the prediction market word list and read them all out at the end of their earnings call…

None of this is currently covered in your employee handbook…

Google Insider Allegedly Made $3.9M in Prediction Market

Recently, there’s been a lot of online discussion accusing a tech employee of betting on internal product milestones and Google search markets. And this person has made a TON of money from it.

Is this legal? If this person is a Google insider, would they be charged with insider trading?

Do Insider Trading Rules Apply to Prediction Markets?

Prediction markets don’t fit neatly into any familiar legal box.

Insider trading laws are built around securities. It assumes brokerage accounts, trades, issuers, blackout windows, and a paper trail everyone pretends to understand.

Prediction markets skip all of that. There’s no stock. No company issuing anything. Just an event, a wager, and a payout.

So when someone asks whether betting on an internal outcome is illegal, the answer is rarely a clean yes or no. It’s more of a long pause followed by, “I need to think about how bad this looks.”

Prediction markets (like Polymarket) treat their event contracts as derivatives regulated by the Commodity Futures Trading Commission (CFTC), not as securities under SEC jurisdiction. Classic insider trading laws (like SEC Rule 10b-5) primarily apply to securities, prohibiting trades on material nonpublic information (MNPI) in breach of a duty. Prediction market contracts generally don’t qualify as securities though…so those strict prohibitions don’t directly carry over.

The CFTC does have anti-fraud rules under the Commodity Exchange Act, which prohibit manipulative or deceptive devices, including trading on MNPI obtained through fraud, deception, or in breach of a pre-existing duty. However:

• This is a narrower standard than SEC rules.

• It requires proving elements like breach of fiduciary duty or fraud in obtaining/using the info.

• In practice, the CFTC has rarely (if ever) enforced insider trading specifically on event contracts in prediction markets.

• Multiple reports and legal analyses describe this as a regulatory gray area, with no blanket ban on using insider info for these bets.

Corporate Policies Were Written for a Different Era

Most insider trading and ethics policies assume that personal profit comes from buying or selling stock. They do a decent job with that.

They do not contemplate employees placing bets on whether their own team hits a deadline or whether a regulator approves something they helped prepare.

That leaves Legal in the awkward position of explaining why something feels wrong even though there’s no sentence in the policy that says, “Please do not gamble on your own work.”

Policies age. Behavior evolves. This is one of those gaps.

Some Jobs Make This Instantly Weird

Context typically matters here.

An employee betting on whether it rains next Tuesday is not the issue.

An employee betting on outcomes they help shape is.

People in finance, engineering, legal, regulatory, compliance, government affairs, and leadership tend to know things before the rest of the world does. Sometimes they’re the reason those things happen at all.

When someone in that position places a wager tied to their work, it stops being clever and starts being uncomfortable.

Even if nothing illegal happened, everyone’s confidence in the system takes a hit.

Regulators Will Eventually Notice

Prediction markets already have regulators watching them, mostly from a commodities and gaming angle. That focus won’t stay narrow forever.

Regulatory frameworks tend to expand when behavior starts producing uncomfortable outcomes. If employees regularly profit from inside knowledge through unconventional channels, enforcement theories will adapt.

Nobody wants their company to be the example cited in the footnote of the first case.

Even the major prediction market platforms (Kalshi and Polymarket) are inconsistent in their rules:

1. Kalshi: Explicitly bans insider trading and anyone with material nonpublic information trading on contracts

2. Polymarket: Has been more lenient with no explicit insider trading ban. Many think insider trading improves accuracy and timeliness of information.

What Companies Are Starting to Do

This doesn’t require overreaction or dramatic policy rewrites. It does require decisions.

Some companies are:

• treating prediction market activity like securities trading for certain roles

• declaring specific topics off-limits

• folding it into conflict-of-interest rules

• setting expectations before someone pushes the boundary

While some may call it paranoia, it’s better to describe it as governance catching up.

Final Thoughts

Eventually, companies will address this through policies, enforcement, or very awkward explanations they wish they’d avoided.

Regulators are also already circling. Expect more government guidance and regulations in the coming months and years.

I expect what continues to happen is people view insider trading in prediction markets as basically legal (although gray) and since it’s much harder to catch, all the illegal activity will just move over to prediction markets until the rules change (both government regulations and company policies).

My ethical warning: Ask yourself, “How would I feel if my trading and bets were published for the world to see?”.

Subscribe now

Disclosure: *This is not legal advice, investment advice, tax advice, or financial advice.

Subscribe now

There was a Forbes piece recently that landed a little too close to home.

Not because it said anything radical, but because it described something a lot of people already know and don’t want to talk about: companies are making important decisions based on work that no one actually checked.

Not “reviewed carefully.” Not “pressure-tested.” Checked.

And the problem isn’t the tools. It’s the confidence.

It’s Sloppiness Wearing a Suit.

If you’ve sat through enough board meetings, diligence calls, or strategy reviews, you’ve likely seen this before:

• A slide looks clean.

• The analysis sounds reasonable.

• There’s a citation at the bottom.

• Everyone assumes someone else verified it.

Nobody wants to be the person who slows things down by asking, “Did we actually read the source?” So the assumption slides through.

That’s how bad ideas become “agreed-upon facts.”

The Legal Examples Are Just the Most Embarrassing Ones

The reason lawyers keep ending up in the news is simple: courts write things down. When a filing includes cases that don’t exist, or quotes that were never said, it’s visible. Public. Awkward.

But that same behavior happens every day outside the courtroom.

In internal memos. In market analysis. In technical reviews. In investment theses.

The difference is that nobody publishes those mistakes…until something breaks.

The Code Problem Is a Perfect Example

One of the more unsettling data points in the Forbes article came from academic research on software development.

A meaningful amount of automatically generated code references libraries that don’t exist.

Not obscure ones. Not outdated ones. Made-up ones.

Which means someone eventually:

• patches it by hand

• works around it

• ships anyway

• updates the documentation later (maybe)

From the outside, everything looks fine. From the inside, nobody is quite sure how things actually work anymore.

This Is How Messes Form Quietly

This kind of problem doesn’t announce itself. It shows up as:

• rework no one can explain

• “temporary” fixes that never go away

• systems no one wants to touch

• reports that don’t quite line up

• diligence questions that suddenly get very specific

By the time leadership notices, the original mistake is buried under layers of confident follow-ups.

Everyone thought someone else had checked.

Why Investors Should Be Nervous (Even If Nothing Looks Broken)

Markets are great at pricing visible risk. They’re terrible at pricing quiet operational messes.

You don’t see this on earnings calls. You hear it later as:

• “unexpected complexity”

• “execution challenges”

• “integration issues”

• “longer-than-anticipated remediation”

Translation: we trusted something we shouldn’t have.

Consultants Don’t Automatically Save You

One uncomfortable point the Forbes piece hints at: outsourcing doesn’t magically fix this.

A polished deck with footnotes is still risky if nobody checked the footnotes. I’ve seen external reports that looked airtight and collapsed the moment someone asked where the numbers actually came from.

The issue isn’t who produced the work. It’s whether accuracy is someone’s job or just assumed.

Habits That Matter

The companies that avoid this don’t have better tools. They have better habits:

• Someone is responsible for checking.

• That person has time to do it.

• Speed isn’t the only thing rewarded.

• Saying “this isn’t ready” isn’t career-limiting.

Those sound basic, but they’re increasingly rare.

The Real Risk Isn’t Error

Mistakes happen. Always have.

The real risk is when mistakes look good enough to pass. When confidence replaces verification. When polish replaces proof. When nobody wants to be the person who slows things down.

That’s what the Forbes article is really pointing at, even if it doesn’t say it bluntly.

And that’s the part lawyers, investors, executives, and boards should be paying attention to now.

Not because something exploded.

But because nothing has…yet.

Subscribe now

The CEO of Mainstreet.com posted that anyone secretly holding two full-time jobs is committing “compensation fraud,” that fraud “doesn’t expire,” and that employers now have an arsenal of legal weapons to pursue clawbacks, restitution, and even civil fraud claims.

Let’s look at “overemployment” from a legal perspective.

There are real legal risks when someone works two full-time jobs. There are scenarios where fraud, breach of duty, or IP exposure become very real.

But is every overemployed worker one discovery away from a multi-claim lawsuit?

Let’s breakdown the risks, the legal considerations, and what business leaders actually need to worry about.

1. “Fraud doesn’t expire.” Technically true. Practically…it depends.

If fraud statutes starts running at discovery, do employers have endless time to sue someone who worked two jobs? Partially true.

Fraud claims in many jurisdictions do have a “discovery rule.”

But:

• Not all claims follow that rule.

• Not every jurisdiction applies it the same way.

• Fraud is a specific legal concept, not “this person annoyed me.”

• “Discovery” isn’t whenever the employer feels like it discovered something. There’s a standard.

A better summary is: If an employee lies on compliance forms, falsifies certifications, or misrepresents conflicts, employers often can pursue claims even if the misconduct happened a while ago.

But this is not a bottomless well of liability.

Fraud isn’t the default. But when it exists, the clock doesn’t bail the employee out.

2. Working two jobs isn’t automatically fraud. Sometimes it’s just a bad idea.

NOT FRAUD

• Working two remote jobs where no exclusivity clause exists

• Doing mediocre work that disappoints a manager but doesn’t violate policy

• Working unconventional hours but still meeting expectations

• Side hustles that don’t violate duty of loyalty

POTENTIAL FRAUD

• Lying on conflict-of-interest disclosures

• Certifying “I have no other employment” when you do

• Falsifying timecards

• Misrepresenting job capacity

• Using company systems or time to work a second job

Fraud is about deception, not existence. The mere fact of two jobs isn’t enough.

Unless, of course, the employee works for literal competitors.

3. IP contamination is a nightmare.

This is the part business leaders underestimate.

If an engineer, PM, senior analyst, or executive quietly holds a second job at an adjacent or competing company, you’re not dealing with “time theft.” You’re dealing with:

• access to source code, roadmaps, models, strategy

• trade secrets that follow them into Zoom meeting #2

• overlapping deliverables that blur who created what

• confidential docs floating between employers on a personal machine

• unintentional “knowledge transfer” that suddenly becomes very intentional in litigation

Once two companies’ intellectual property gets mixed in the same person’s brain, there is no elegant way to untangle the mess.

I’ve seen this happen. It’s expensive. It’s stressful. It makes everyone feel like they’re living in a Cold War spy movie. And you absolutely can’t “return” contaminated knowledge.

The post calls this “radioactive.” That part is not wrong.

4. Yes, employers can pursue clawbacks, but not for everything

Clawbacks and restitution aren’t a new invention. Employers have always had mechanisms:

• Contractual clawbacks (sign-on bonuses, equity, relocation, incentives)

• Unjust enrichment theories

• Negligent or intentional misrepresentation claims

• Recoupment of wages in narrow scenarios (with many restrictions)

• Offsets against future payments (when legally permissible)

But…Wage laws are strict.

You can’t say: “We think you underworked. Please return your paycheck.”

Wages aren’t refundable just because output didn’t match expectations. (If they were, we’d have no corporate executives left.)

Evidence must be airtight.

You need logs, timecards, credentials, overlapping meetings, device telemetry, system access—proof that would survive discovery.

Employers need to avoid overreach. Aggressive clawback attempts can trigger:

• retaliation claims

• wrongful termination suits

• claims under state wage protection laws

• discrimination arguments if enforcement isn’t consistent

• privacy lawsuits if monitoring is excessive

Clawbacks are surgical instruments, not grenades.

5. “Fraud becomes provable” — maybe. But employers now have their own risks.

False positives

Most detection tools aren’t magic. People with caregiving responsibilities, disabilities, unconventional work styles, or global schedules may look like “dual-employees” on a graph.

Surveillance laws

Monitoring remote workers can be a legal minefield:

• U.S. wiretap laws

• Eavesdropping statutes

• Biometric privacy laws

• EU/UK worker monitoring limits

• Works councils

• Notice requirements everywhere

You can’t run a secret digital sting operation and expect smooth sailing.

Litigation risk

Botched investigations are expensive:

• wrongful termination

• retaliation

• breach of contract

• defamation

• constructive discharge

• whistleblower claims

The employer’s process matters as much as the employee’s conduct.

6. Overemployment isn’t new. Technology just makes it louder.

People have always held multiple jobs. But remote work + SaaS logs + digital trails + compliance attestations mean:

• it’s easier to see

• easier to prove

• harder to deny

• harder to ignore

Legally, the right question isn’t: “How many jobs do you have?”

It’s: “Did you lie, breach, leak, or misuse anything?”

7. What business leaders should actually do (without freaking out)

• Clean up your employment agreements

  • exclusivity clauses

  • conflict disclosure requirements

  • IP ownership language

  • confidentiality obligations

  • invention assignment agreements

• Add real conflict-of-interest certifications. Annual, signed, specific, not vague HR checkboxes.

• Tighten system access controls. If employees have access to sensitive docs at midnight for one company and 2:00 AM for another…yeah.

• Audit roles for IP exposure. Some roles (engineering, data science, strategy, product) carry inherent risk.

• Build a disciplined investigation process. Not a rumor mill, something structured like a termination pipeline.

• Don’t over-rely on detection vendors. Logs don’t tell stories. People do. Investigations require context.

• Keep wage laws in mind. Do not attempt DIY clawbacks. Your payroll team will quit and your legal team will follow.

The better headline. Overemployment can involve fraud. It can involve IP theft. It can involve breach of contract.

But it can also involve:

• a burned-out employee

• a badly designed job

• unclear expectations

• or someone trying to pay rent in the year 2025

The legal tools exist but they are scalpels, not sledgehammers.

If companies want to take action, they need to do it carefully, thoughtfully, and with actual legal theory.

Subscribe now

*This newsletter is informational only and is not intended as legal, tax, or investment advice

Subscribe now

For today’s post, I asked Rachel Harris (GC and AI Governance Officer at a Series D tech company) to write a guest post on the hidden customer costs that no one thinks about and why your legal team should be involved in ICP discussions.

Legal’s View on ICP

As a General Counsel in tech, I see deals close all the time that look identical on paper—same ARR, same contract structure—but create wildly different obligations for the company.

• One customer triggers quarterly compliance attestations that never end.

• Another embeds audit rights that consume Security and Engineering for weeks each year.

• A third demands contractual commitments that lock you into roadmap decisions you can’t easily reverse.

Finance sees the revenue. Legal sees the obligation.

These obligations have a cost structure that most Ideal Customer Profiles (ICPs) never account for.

The Pattern Often Overlooked

Here’s what I’ve learned: customer type and vertical drive obligation exposure in ways that don’t show up in traditional sales or finance models.

A regional bank and a tech startup might pay the same subscription fee, but they don’t trigger the same regulatory requirements, security controls, insurance provisions, indemnification scope, or audit obligations. Some of those costs are one-time. Many are recurring. Almost all of them require sustained internal capacity that’s difficult to price and even harder to unwind.

This matters more now than ever in the age of AI because the regulatory surface area is larger and less settled. New data flows create new compliance obligations. AI outputs create new liability questions. Transparency requirements create new documentation burdens.

And every one of those requirements shows up differently depending on who your customer is, not just what your product does.

Traditional ICP models are built to capture: who can buy, how much they’ll spend, and whether they’ll expand. Traditional finance models are built to capture direct costs: COGS, infrastructure spend, etc. What can be missed is obligation: the sustained capacity commitments that don’t flow through standard accounting but compound across teams and quarters.

Obligation Compounds

The challenge isn’t that Sales and Finance don’t care about costs. It’s that many of these costs are invisible until they’re already embedded in the operating model.

• Contract negotiations that extend 6+ months don’t show up as COGS. They show up as Legal, Security, and Sales capacity that can’t be redeployed elsewhere.

• Custom security controls required by a single vertical don’t appear as direct costs. They appear as engineering drag and architectural constraints that slow down the roadmap for everyone else.

• Annual SOC 2 audits are standard, but when three enterprise customers each demand their own bespoke audit process on top of that, the marginal cost is real; it just doesn’t get allocated cleanly.

By the time Finance can model the impact clearly, the contractual commitments are already signed.

Where This Shows Up: The Regulated Enterprise Customer

Take a healthcare or financial services customer. They’re often strategic wins: credible logos, large contracts, validation for the product. They also come with obligations that persist long after the deal closes.

You’ll face industry-specific regulations you didn’t have to meet before. Security frameworks that require new controls or certifications. Contractual representations and warranties that expose you to ongoing compliance work. Audit rights that give the customer visibility into your operations on their timeline, not yours. And indemnification provisions that broaden your risk surface in ways that compound with each similar deal you sign.

Some of this is manageable. Some of it is expensive. And some of it reshapes your business model in ways you didn’t anticipate.

A single $500K healthcare contract can easily consume 400+ hours of Legal, Security, and Engineering time in Year 1 alone. Not for implementation, but for compliance attestations, audit preparation, and bespoke security reviews. That’s $200K+ in fully-loaded cost that never appeared in the deal economics.

That’s not a Finance failure. It’s a timing problem. Legal sees these obligations at contract review, when they’re still negotiable. Finance sees the cost impact quarters later, when the commitments are already locked in. By then, the only levers left are pricing adjustments or renegotiation (both expensive and often impractical).

ICPs Built Without Legal Input Miss Part of the Picture

Most ICPs are built by Sales and Marketing, sometimes with Finance input on unit economics or pricing models. The goal is to identify who can buy, who will expand, and who fits the growth model.

What’s missing is the question Legal is uniquely positioned to answer: What does it actually cost—in obligation, risk, and sustained capacity—to serve this customer over time?

This isn’t about being risk-averse. It’s about being precise. Some enterprise customers are worth the complexity. Some aren’t. And the only way to know the difference is to model the obligation structure before it’s embedded in your contracts and operating model.

What the Partnership Actually Looks Like

When Legal and Finance build ICPs together, the questions evolve:

• Which regulatory obligations are triggered by customer type, not product features?

• How many annual audits, assessments, or compliance reviews does a given vertical realistically require?

• Which contract terms create recurring work that never appears in a pricing model?

• What’s the true opportunity cost when Legal, Security, and Engineering resources are dedicated to one customer’s demands?

• Where do we have contractual flexibility, and where are we locked in?

The exercise is operational and strategic. And it’s the difference between a profitable ICP and one that quietly erodes margin for years.

Why This Matters Now

AI products accelerate this dynamic. Regulatory scrutiny is higher. Data obligations are more complex. Transparency and auditability expectations are stricter. And customers in regulated industries are asking harder questions earlier in the sales process.

If your ICP assumes that all revenue carries the same obligation structure, you’re forecasting with blind spots.

Legal can help surface cost drivers that traditional models might miss. And obligation, once embedded, is expensive to unwind.

Where to Start

If you’re a GC or CFO looking to enhance your modeling and ICP frameworks:

• Start with your most recent 5-10 enterprise deals. Map the actual Legal, Security, Support, and Engineering hours consumed in the first 12 months post-signature.

• Identify which obligations were one-time vs. recurring. Most teams underestimate how much “recurring” actually recurs.

• Bring those POVs into the next ICP planning session for cost modeling. Ask them to walk through the obligation structure by customer vertical.

• Build these insights into your pricing models before the next enterprise deal closes.

The goal isn’t to avoid complexity, but to price for it and choose it intentionally.

Final Thought

Revenue is easy to model. Obligation is harder. But if your ICP doesn’t account for what your company is actually committing to, it isn’t a strategy. It’s a hope.

For companies still building their ICP frameworks, the challenge is often definitional: Sales thinks of ICPs as “who will buy,” Marketing thinks of them as “who we should target,” and Finance thinks of them as “who is profitable to serve.” Legal adds a fourth lens: “who can we realistically commit to serving without breaking the business model.”

Footnotes:

• Thanks Rachel for the great write-up! So many companies fail to consider these additional costs

• Subscribe to this weekly newsletter and share it with your legal team

  Subscribe now

Subscribe now

The European Commission just unveiled something called the Digital Omnibus (a bundle of updates to the GDPR, AI Act, Data Act, ePrivacy rules, and several other regulations that have kept legal teams heavily caffeinated for years).

Officially, the goal is simplification.

Which is charming, because the EU’s previous attempts at “simplification” have created entire job markets for privacy attorneys, consultants, and UX designers trying to make cookie banners slightly less unhinged.

Still, this package matters. And unlike some prior efforts, parts of it might actually make life easier…eventually.

Here’s what I think is worth understanding, without reviewing 700 pages of amendments or scheduling a webinar to unpack a footnote.

1. High-Risk AI Obligations Are Getting a Delay and Everyone Is Quietly Relieved

A major part of the Omnibus pushes back certain high-risk AI requirements to December 2027.

The official explanation mentions “orderly implementation.”

The unofficial one: everyone told the Commission the original timetable required supernatural staffing levels.

This extension creates an odd in-between period:

• Teams that invested early now don’t know whether they’re ahead or just prematurely enthusiastic.

• Teams that waited now get to say, “We’re pacing ourselves.”

• Vendors will happily sell “AI Act readiness packages” that will need to be rewritten as soon as Parliament negotiates the final text.

But don’t mistake a delay for a free pass. Regulators will still expect competent, well-documented practices now, even if the rules they’ll use to judge those practices aren’t fully final.

2. The Omnibus Tweaks the Definition of Personal Data (and That Will Echo Everywhere)

One of the most consequential proposals involves clarifying what counts as:

• personal data,

• pseudonymized data, and

• data that can be used for AI model training without needing the legal equivalent of a permission slip.

If these definitions expand the lawful use of pseudonymized data, organizations will have more flexibility, but they’ll also need to revisit:

• DPAs,

• vendor onboarding,

• AI training workflows,

• and any contract clauses that assume the old definitions.

And yes, it will reignite the eternal debate between engineers (“it’s anonymized because I removed the names”), lawyers (“…that’s not how this works”), and product teams (“why can’t we just get ‘implied consent’ for this?”).

Expect contract reviews.

Expect policy updates.

Expect someone to have a strong opinion about hashing.

3. The Cookie Rules Might Get Cleaner…But History Suggests Caution

The EU says it wants to reduce “cookie fatigue” and streamline consent burdens.

This is a noble mission. But the last time the EU tried to make cookie rules clearer, we ended up with:

• banners that cover half the screen,

• entire consulting firms built around button placement,

• and at least one DPA insisting that scrolling “cannot constitute informed rejection.”

The new direction might genuinely improve things…or it might invent a new style of banner we’ll all love to hate.

We’ll know soon enough.

4. The Omnibus Has a New Tone: Less “Stop Everything,” More “Let’s Be Practical”

The most interesting part of this announcement isn’t any single amendment. It’s the overall posture.

For the first time in a long time, the Commission is signaling that it wants digital rules that support innovation instead of slowing everything to a crawl.

It’s not deregulation.

It’s not loosening requirements.

It’s a recognition that AI development is moving fast, and Europe wants to remain part of that story.

For companies, the takeaway is simple: Assumptions based on last year’s timelines and definitions may no longer hold. Compliance plans built six months ago may already need a tune-up.

5. The Transition Period Is the Hard Part

The messy reality is that:

• Existing laws are still in effect,

• The Omnibus isn’t final,

• Some rules are being extended,

• And regulators expect companies to act responsibly now, even while the legal framework is being edited.

It’s the regulatory equivalent of driving while construction crews are repainting the lanes in front of you.

You can keep moving, but you need to pay attention.

6. Practical Things to Reassess

Here’s what companies should be thinking about quietly, practically, without the dramatic “action item” label:

• Review whether your current AI governance program is built around the original 2025–2026 timelines; some dates are no longer accurate.

• Scan your vendor and customer contracts for clauses tied to definitions that the Omnibus may update.

• Re-evaluate where you rely on pseudonymization; permissible uses may change.

• Monitor whether any member states diverge ( tiny differences become operational headaches fast).

• Avoid redesigning your full compliance program until the amendments settle; there will be another round of edits.

None of this requires panic. It does require attention.

Final Thought

Europe Isn’t Rewriting their Rulebook. It’s Rewriting the Footnotes That Control their Rulebook

The Digital Omnibus won’t tear down the GDPR or the AI Act.

Rather, it adjusts the parts that weren’t aging well, clarifies definitions that were creating more questions than answers, and finally acknowledges that the original timelines were a bit…optimistic.

Some changes will help organizations. Some will complicate things. But all of them matter.

Because when Europe updates the details, those details eventually show up in your compliance roadmap, your vendor contracts, your AI workflows, and your next product launch meeting.

Footnotes:

• Reply to this email if you have any legal questions or have feedback on the content.

Subscribe now

So…Where Exactly Is Our Payments Vendor?

Keith Rabois, VC at Khosla Ventures, kicked off a firestorm on Twitter/X this week by publicly accusing a major global payments provider (Airwallex) of being an unintended data pipeline into China.

The kind of tweet that makes half of tech Twitter go silent, and makes every CISO immediately open their laptop like they’re defusing a bomb.

Before we go any further, let’s get something clear before we go any further:

These are allegations, not proven facts.

But the reason the post spread faster than a phishing scam is because it hits a nerve companies never want to talk about: If your vendor has people, systems, or entities in another country, then that country’s laws apply to your data.

It’s not espionage. It’s not intrigue. It’s jurisdiction.

(Which is somehow less fun than espionage but way more dangerous.)

The Part Companies Pretend Isn’t Relevant

Public info tells us the Airwallex has:

• HQ in Singapore

• Big engineering + ops teams in mainland China and Hong Kong

• A China-regulated payments license

• Major Chinese investors

None of this is misconduct. But it’s absolutely relevant.

Because if your vendor operates, or has its decision makers or engineers, in a foreign jurisdiction, then the laws of that jurisdiction come attached like a warranty nobody reads.

The Chinese Law Everyone Tiptoes Around

China’s National Intelligence Law (2017) says individuals and organizations must:

“support and cooperate with national intelligence work,”

and…

“keep that cooperation confidential.”

Add the Data Security Law and Cybersecurity Law, and you now have a country with authority over:

• data stored in China

• infra operated from China

• companies regulated in China

• employees physically sitting in China, even if serving foreign customers

Legal scholars call this a broad scope of authority.

CEOs call it “Wait…what?”

The U.S. Government Is Paying Attention Too

The U.S. already dropped a legal anvil on this earlier this year: The 2024 Executive Order on Protecting Americans’ Sensitive Data

The EO directs DOJ, DHS, Treasury, and Commerce to block or restrict U.S. data from flowing into “countries of concern,” specifically including China.

The EO flags:

• financial transactions

• payroll data

• employee PII

• corporate payments

• anything revealing supply chains or operational patterns

You know…the exact things your payments provider processes every minute.

The EO doesn’t ban these vendors outright. But it screams: “At least know who’s touching your data.”

Why This Story Exploded: Everyone Realized They Might Not Know

Most vendor reviews are basically:

• SOC 2?

• ISO cert?

• Pen test?

• “Very professional-sounding” security questionnaire answers?

Meanwhile no one is asking:

• “So…where are your production engineers physically located?”

• “Which country’s laws apply to them?”

• “Where does our data go when something breaks at 3 AM?”

• “Can a foreign government legally demand access and would we ever be told?”

• “Is the failover region somewhere we’ve never discussed?”

This is how companies discover “accidentally” that their payroll vendor sends logs to a city no one can pronounce, or their payments processor uses offshore contractors to debug fraud alerts.

I once reviewed a contract where the vendor proudly advertised “U.S-only data processing,” and then casually mentioned their Shanghai engineering team had “support visibility.”

Support visibility is a lovely phrase that translates to: “full access.”

Where This Gets Legally Messy

Not hypothetical. Real problems:

1. Your privacy notices may be flat-out wrong. If you said “data stays domestic,” and it doesn’t, that’s a violation, sometimes a major one.

2. Your contract won’t save you. No DPA overrides national intelligence law.

3. Regulators will ask very specific questions. “Where is this processed?” cannot be answered with “regionally.”

4. Boards absolutely hate international surprises. Especially involving payroll or payments.

5. Your cyber insurer will raise your premiums. Underwriters already ask about offshore access. Now they’ll underline it.

The Questions Every Company Should Ask, Today

If you ask nothing else, ask these:

• Who has production access, and where are they located? Actual teams. Actual cities.

• Where is our data processed, backed up, and mirrored? If they send a marketing diagram, you already have the answer.

• Are any of your employees required to comply with foreign intelligence laws? You’ll know by the pause.

• Can you guarantee that encryption keys never leave approved jurisdictions? This is where most vendors get nervous.

• Can you notify us if any government requests access? In some countries, the answer is legally “no.”

• Do your investors have information rights that could expose our data indirectly? This one separates the adults from the interns.

What to Say When Your CEO Slacks You the Tweet

Use this:

We’re not assuming the tweet is accurate. But the underlying issue applies to any vendor with operations in certain jurisdictions. We’re reviewing where our vendors’ access and processing actually occur.

It shows control without panic. Boards love that.

The Actual Point Here

You don’t need to know whether the tweet was right or wrong.

You just need to know this: If you don’t understand where your vendor’s people and systems are, you don’t understand where your data is.

And in 2025, that’s not a small detail…

Footnotes:

• Reply to this email with any legal topics you want to read about!

• Share this newsletter with your friends.

Share

*Nothing in this post is legal, investment, tax, or financial advice. This is for educational purposes only.

Subscribe now

In the last year, a quiet shift has been happening in AI. It’s the kind of shift that causes investors to frown at spreadsheets, product leaders to stare into the middle distance, and lawyers to wonder whether they should start brushing up on restructuring clauses again.

Here it is: Foundation models are improving so quickly that many AI applications built on top of them no longer have a defensible advantage.

Not in the abstract. Not hypothetically. Right now.

And nowhere is this clearer than in legal tech.

Let’s walk through two examples that tell the entire story without naming the 47 other companies quietly experiencing the same thing.

1. Harvey: The billion-dollar legal AI that suddenly has competition from…Word

Harvey raised north of $1 billion, became the industry’s favorite topic at legal conferences, and positioned itself as the future of legal work.

But in the last six months, conversations among lawyers have started to sound like this:

• “Our lawyers are just using Copilot and it’s close enough.”

• “Litera rolled out similar features, and, inconveniently, they’re free.”

• “I vibe-coded the features I need”

• “Usage numbers are…lower than anticipated.”

None of this is a moral judgment on Harvey’s team.

They built something impressive.

The problem is simple: The newest foundation models (GPT-5.1, Claude, and friends) are now so capable that the “specialized legal AI” gap has narrowed to a sliver.

Once Microsoft bundles that capability into a product firms already pay for, CFOs start asking dangerous questions like: “Remind me why we have two tools that do the same thing?”

Some firms are locked into multi-year contracts signed during peak AI euphoria.

But renewal cycles are coming, and they’re going to be educational.

2. Casetext / CoCounsel: A $650M acquisition colliding with a rapidly moving floor

Thomson Reuters bought Casetext for $650 million, which was a rational decision at the time. CoCounsel was ahead of everyone else. It worked. Lawyers liked it.

Then the model layer leveled up…dramatically.

And suddenly:

• The base models outperform CoCounsel on standard legal tasks

• Customers begin shifting back to general-purpose tools

• TR starts investing in native foundation model integrations

CoCounsel didn’t fall behind; the ground moved faster than anyone expected.

It’s hard to maintain a moat when the river doubles in speed every quarter.

3. This is happening across every industry

Legal just happens to be the most obvious current example.

But the same pattern is occurring in:

• sales automation

• compliance workflows

• research and summarization tools

• customer support

• healthcare triage

• coding assistants

• contract analytics

• financial modeling assistants

Startups built thin wrappers around foundation models.

They raised large rounds.

They sold a compelling story.

Then the base models matured faster than projected, making those wrappers look a lot more like features than defensible products.

Unless a company has:

• proprietary datasets

• deep operational integration

• regulatory insulation

• or its own model innovation

…it’s vulnerable.

“Fine-tuning” doesn’t count as a moat.

4. The business consequences are already here

This shift isn’t theoretical. It’s showing up in contracts, budgets, roadmaps, and leadership meetings.

• Long-term AI contracts suddenly feel like outdated gym memberships: Everyone signed up with enthusiasm. Now many are quietly wondering how to cancel.

• Acquisition valuations look more fragile: When a $650M purchase now competes with a free feature inside a productivity suite, the math changes.

• Shadow AI becomes unavoidable: Employees migrate toward whatever tool actually works best, not necessarily the one with procurement’s stamp of approval.

• Vendor stability is harder to assess: When product differentiation depends on staying ahead of the next model release, vendor viability becomes a moving target.

This isn’t anyone’s fault. It’s the market adjusting to a world where innovation cycles are measured in months, not years.

5. Is this an AI bubble? A controlled correction? Something in-between?

It’s not a bubble in the “this tech is fake” sense. The tech is breathtakingly real.

But the valuations placed on vertical AI apps assumed a slower, more predictable evolution of the underlying model layer.

That assumption didn’t hold.

The result is a correction (smooth for some, bumpy for many).

The apps that survive will be the ones with:

• real data advantages

• workflow lock-in

• measurable performance superior to base models

• or distribution channels foundation models cannot easily replace

Everything else gets squeezed.

6. Practical implications for companies deciding what to build or buy

A few principles are emerging:

• Compare every vertical AI tool to the newest base model before buying. The results will surprise you.

• Avoid long-term commitments. Three-year AI contracts age like dairy.

• Design workflows that can tolerate tool churn. The tool you use today may not be the tool you use in six months.

• Guard data portability like a critical asset. It’s the only thing that lets you switch vendors without a migraine.

• Assume rapid capability changes. Plans that rely on model stability are really just wishful thinking in a trench coat.

Final Thought

We’re in an era where: The more powerful foundation models become, the more they erase the products built directly on top of them.

This isn’t catastrophic. It’s simply reality catching up to the hype.

Some AI applications will thrive because they deliver value that persists beyond the model layer. Many won’t.

The smartest organizations aren’t trying to predict the winner. They’re building flexible systems that can adapt as the foundation shifts beneath them.

Because in AI, the ground is always moving and the companies that stay upright are the ones that expect it.

Subscribe now

Subscribe now

Yes, a Nation-State Used Anthropic to Automate Parts of a Hack. No, It’s Not Skynet.

Last week the internet lit up with the kind of headline that makes CISOs stop mid-coffee and makes GCs wonder if they should go back to bed:

Chinese hackers used Anthropic’s AI tools to automate large parts of a cyber-espionage campaign.

Anthropic disclosed that a state-sponsored threat actor chained together AI agents to help run portions of their recon, exploitation, and lateral movement. Yes…an AI-assisted kill chain.

This is the most advanced publicly confirmed adversarial AI workflow we’ve seen so far. It’s important, serious, and noteworthy. But before anyone panics, before boards start asking “is ChatGPT going to hack us?”, before vendors start selling “AI threat shields” at $80K per seat…let’s take a breath.

Because what happened here is not the rise of machine super-hackers.

It’s the rise of automation that makes mediocre attackers…slightly less mediocre.

And the lesson for companies is not “fear AI.” It’s “design secure AI systems or you will get owned by someone using them.”

What Anthropic Actually Found

Anthropic’s transparency deserves real praise. Instead of burying this in a “research note,” they disclosed it publicly, engaged with the US government, and acknowledged that their platform was abused.

That alone sets them apart.

Here’s what they reported:

• A Chinese state-sponsored actor (likely PRC-backed APT) used their tools.

• AI was used to automate parts of:

  • reconnaissance

  • target profiling

  • exploit chain assembly

  • lateral-movement planning

• Multiple agents were stitched together into an orchestration workflow.

This is the first time we’ve seen a vendor publicly confirm AI-chained adversarial automation at this level.

Not hypothetical.

Not “proof-of-concept.”

In the wild.

That alone makes the incident worth paying attention to.

Here’s the Missing Piece (and It Matters)

As security researcher Marcus Hutchins pointed out, there’s a glaring gap: We don’t know what the AI actually improved.

• Was AI just generating Python scripts and nmap commands faster?

• Was it drafting phishing emails?

• Was it ranking potential targets?

• Was it summarizing logs?

• Was it outlining exploitation steps that any intern with Metasploit could replicate?

• Or was it doing something genuinely novel?

We don’t know. And until we do, the risk narrative is incomplete.

We’ve seen more detailed adversarial AI analysis from Google’s threat intelligence teams.

Those reports showed:

• actual prompts used by attackers

• failed outputs

• hallucinations and error rates

• where AI sped things up and where it absolutely did not

• workflow diagrams

• code samples

Without that level of detail, defenders are left guessing.

So What Really Happened? Likely This:

This wasn’t an AI mastermind. This was a threat actor using AI the same way your employees already do:

• To automate annoying work.

• To summarize complexity.

• To make mediocre practitioners faster and more scalable.

• To perform the boring parts of a kill chain:

  • Scanning

  • Fingerprinting

  • IOC mapping

  • noisy exploit enumeration

  • default-credential hunting

  • privilege-escalation playbook generation

In other words: AI is becoming the intern of cyber-espionage.

The intern that works 24/7, doesn’t sleep, and doesn’t complain about Jira tickets.

Not unstoppable.

But absolutely something you need to plan for.

The Takeaway for GCs and Execs: This Is the Beginning of “Commodity State-Level Threats.”

Historically, only the top-tier APTs had the infrastructure, the expertise, the tooling and the operational discipline to run full-spectrum intrusions at scale.

AI lowers those barriers.

Think of AI as: “State-sponsored hacking, but available at startup prices.”

The best attackers will still be the best attackers.

But the mid-tier attackers?

They’re the ones AI will supercharge because AI is best at scaling mediocre-but-repetitive tasks.

Attackers don’t need AI to zero-day your systems.

They need AI to:

• chain exploits efficiently

• find the weakest part of your cloud posture

• script and deploy variations of known attacks

• automate persistence strategies

• generate hundreds of tailored phishing emails

• run OSINT at a depth humans wouldn’t touch

This is the scenario defenders need to model.

Not “AI can hack you autonomously.”

AI can make human hackers 4x faster.

And that’s enough to change the threat landscape.

Why This Should NOT Cause Panic, But Absolutely Should Trigger Action

Most companies will react to this story in one of three ways:

1. Panic: “AI is hacking the world! Shut everything down!”

2. Denial: “This is overhyped. AI can’t code reliably. We’re fine.”

3. The Correct Reaction: “AI in adversarial workflows is real. We need to harden our systems before mediocrity scales.”

This is not a crisis. It’s a turning point.

Because if AI is now being used by APTs to automate the dull parts of a kill chain, that means:

• Your detection pressure goes up

• Your window to contain incidents shrinks

• Your security program can’t rely on “they won’t bother”

• Your risk modeling must assume adversarial automation

The GC’s Version: What This Means Legally

This is where you come in.

There are five areas every GC should be thinking about today:

1. AI-augmented attacks = faster breach notification cycles

If attackers accelerate, detection-to-discovery windows shrink. Your breach notification timeline will too.

Annual tabletop exercises? Not enough.

Do them quarterly with adversarial AI scenarios baked in.

2. Your vendors are suddenly a bigger liability

Attackers can now use AI to scan your supply chain faster than it updates its SOC 2. Vendor risk questionnaires about “AI risk” should move from optional → critical.

You need to know if your vendors run:

• outdated models

• exposed inference endpoints

• no prompt-injection defenses

• AI agents without guardrails

If you don’t know how your vendors are using AI, then you don’t know your attack surface.

3. Boards need a new type of cyber update

Boards have moved past “What is ransomware?” Now they need:

• What adversarial AI means

• What controls we’re adding

• How it changes our risk posture

• How fast a breach could propagate

This is not fearmongering, it’s governance.

4. AI model governance is no longer optional

If you’re building or integrating AI into your own products, guess what?

Attackers will soon target:

• your inference endpoints

• your model inputs

• your agent workflows

• your fine-tuning datasets

Exposure of model behavior = exposure of attack surface.

5. Your AI Use Policy must address agents

LLMs are one thing. Agents are another.

If your employees are chaining tools together with AI to interact with internal systems, you are:

• one misfire away from privilege escalation

• one jailbreak away from data exfiltration

• one misconfigured agent away from “ChatGPT deleted our Jira board”

Your policy should reflect that.

What Companies Should Be Doing Right Now

1. Assume attackers are already using AI. Because guess what…they are.

2. Run an internal red team using AI agents. If you can hack yourself with AI, assume China can too.

3. Lock down your inference endpoints like they’re production databases.

4. Inventory every AI agent in your environment. If you don’t know your agents, you can’t secure your agents.

5. Test for prompt injection everywhere. If your system can be convinced to “just run this one command,” that’s an RCE vulnerability with extra steps.

6. Add “AI risk” to every tabletop exercise. If legal isn’t sweating, the exercise isn’t training.

7. Require AI-usage transparency from vendors. If a vendor says “we don’t use AI,” assume they definitely use AI.

8. Treat any AI automation that touches production as critical infrastructure. Because attackers will.

What This Means Strategically

We are entering the era of AI-powered cyber conflict, but not the Hollywood version.

Not intelligent agents composing Beethoven while cracking RSA.

More like:

• 40% faster recon

• 60% faster code generation

• 80% faster phishing campaigns

• infinite patience for experimentation

• unlimited trial-and-error at zero marginal cost

Attackers don’t need brilliance. They need scale. AI is scale. And that is a strategic shift.

Final Thought: Don’t Fear AI. Fear What Happens Without Secure AI.

The right takeaway from the Anthropic incident is not: “AI has turned nation-states into super-hackers.”

It’s “AI has turned nation-states into organizations that don’t waste their experts’ time.”

Attackers will automate the boring parts.

Defenders must automate the boring protections.

This is the moment to double down on:

• secure-by-design models

• agent safety

• input validation

• monitored toolchains

• and architectural governance

Because if attackers can stitch AI agents into kill chains, then every company should be stitching secure agents into their defense chains.

Footnotes:

• Want to be a sponsor and reach in-house legal teams? Reply to this email

• Subscribe and share with your legal friends

  Subscribe now

Subscribe now

You’ve seen the headlines:

Startup reaches $1B valuation with breakthrough AI automation.

But the story you don’t see: “Breakthrough AI” = two exhausted founders eating Costco pizza, manually performing the AI tasks in a San Francisco living room they can’t afford.

This week’s example? Fireflies.ai’s co-founder admitted they charged $100/month for an “AI notetaker”…that was actually him and his co-founder dialing into meetings silently and typing like court reporters on Monster Energy.

And honestly? Respect.

It worked.

But for GCs?

This is your cautionary tale of the year.

Because if you’re trusting a vendor’s “AI platform,” there is a non-zero chance that behind the model there is a human named Fred who has never passed a background check and is currently taking notes on your confidential board meeting from a futon.

Let’s talk about how to survive this era of AI hype without becoming the star of the next “lol look at this vendor” thread on Twitter.

Lesson 1: The Demo Is a Lie (or at least a work of fiction)

Let me tell you something from years of seeing how the sausage is made: If the founder keeps saying “Our AI does…” but cannot, in fact, show you the “AI” doing anything in a live workflow, you are about to buy a dream and a prayer.

Fireflies admitted it: They validated the business by being the AI.

I’ve seen this movie too:

• The “AI contract analyzer” that was actually three offshore paralegals

• The “AI red-team tool” that just ran nmap and sent you a PDF

• The “AI onboarding chatbot” that forwarded all questions to an intern named Chloe

• The “AI policy generator” that was 100% ChatGPT plus some light jazz in the UI

AI vendors think they’re selling vision.

GCs think they’re buying capability.

Reality: everybody is lying to each other politely until renewal.

Lesson 2: If they can’t explain the model, you’re not buying a model

Here’s a vendor red-flag checklist for early-stage AI:

And my favorite: “We can’t disclose the architecture for IP reasons.”

Translation: “We don’t know what the architecture is because the engineer who built it left.”

Lesson 3: The real risk isn’t fake AI, it’s undisclosed humans

Fireflies sent humans into private meetings. Humans listened to strategy, customer info, internal issues, maybe even financials.

• Would a regulator call that unauthorized access?

• Would a customer call that a breach?

• Would your CEO call that “WHY DIDN’T LEGAL CATCH THIS!?”

Yes, yes, and aggressively yes.

Here’s the part people forget: Human-in-the-loop = human-with-your-data.

There is a MASSIVE legal difference between: (a) your confidential information touching an LLM and (b) your confidential information touching Kevin sitting cross-legged on an Ikea rug.

If your AI vendor does not explicitly state whether humans are involved, assume the answer is: “More humans than you think and fewer guardrails than you hope.”

Lesson 4: Vendor diligence is now a full-contact sport

Stop asking AI vendors, “How does your AI work?”

That gets you TED Talk answers. Instead ask:

1. Who or what touches customer data? (Name every human.) If they hesitate? Red flag.

2. Do contractors ever see customer data? If the answer is “only sometimes,” the answer is “yes.”

3. Do you store prompts? For how long? Where? If they say “temporarily,” ask: define temporarily.

4. How many SOC-2 controls require human action? Look for the smirk that says “most of them.”

5. Could your system function if every human left tomorrow? If they laugh, your AI is fake.

Lesson 5: The contract is your only actual protection

Here are the clauses that matter:

1. Human involvement disclosure

Make them state, clearly, who touches your data.

2. Data location & residency requirements

You don’t want your board notes in a Dropbox folder labeled “AI training stuff – DO NOT DELETE.”

3. Security posture requirements

Minimum controls. Written. Enforceable.

4. Right to audit AI workflows

If they refuse, they’re hiding Kevin.

5. Post-termination data deletion (with certification)

Not “we think it’s deleted.”

“Here is proof.”

6. No model training on your data

Unless your CEO enjoys surprise features announced on a blog post.

Lesson 6: Startups Validate Manually But Scale Requires Reality

I’m not dunking on Fireflies. Their founder admitted what many founders won’t: they validated manually, survived, and built something real.

That honesty deserves applause. But here’s the nuance your audience cares about:

Manual validation is fine.

Manual production is NOT. Especially when:

• customer data is involved

• meeting content is confidential

• sales calls contain financial projections

• employees share HR issues

• executives discuss strategy or layoffs

This is where GCs get very twitchy. Because if the “AI notetaker” is typing from someone’s living room, congratulations: You now have unvetted individuals inside your most sensitive conversations.

Lesson 7: Don’t be the GC who approved the AI vendor with “two humans and a dream”

Your CEO wants AI tools. Your product team wants AI tools. Your board wants AI tools.

But when the next Fireflies-style disclosure drops (and trust me, it will) the only question will be:

“Did Legal ask the right questions?”

So ask them. And then ask them again.

And then ask where the founders are currently sitting while the “AI” runs.

Final Thought: AI hype won’t kill companies, undisclosed humans will

The real danger isn’t fake AI. It’s fake AI plus real data.

AI will transform everything. But during this period of “magical AI demos,” “agent orchestration,” and “trust us, it scales,” remember this:

Behind every early-stage AI product is either a GPU cluster…or a guy named Fred eating pizza.

Your job is to know which.

Subscribe now

So let’s start with the headline: The Central Bank of Ireland just fined Coinbase €21.5 million for anti-money-laundering (AML) failures last week.

The reason? A “coding error” in their transaction-monitoring system that left billions of euros in transactions unchecked…for three years.

However, this is not a crypto story. This is a compliance systems story. Because if you replace “AML” with “privacy,” “AI,” “export,” or “sanctions,” every GC in tech is one log-rotation away from starring in their own version of this movie.

The Backstory (and Why It Hurts)

Between 2020 and 2023, Coinbase Europe’s automated AML engine had a logic flaw that effectively excluded a large portion of transactions from monitoring.

We’re talking €176 billion in transactions that skipped review.

When they fixed it, they self-reported and back-reviewed the data; discovering 2,700 suspicious transactions that should’ve been escalated years earlier.

The Central Bank’s tone? Disbelief mixed with irritation. Their statement could be summarized as: “Automation is not a substitute for oversight.”

Translation for GCs: “You can outsource the work, not the accountability.”

The Lesson: “Tech Glitch” Is Not a Defense

In-house, we love to blame bugs. I’ve seen it a hundred times: a policy says “continuous monitoring,” IT says “the script runs daily,” and Legal assumes it’s all good.

Until it’s not.

The Coinbase case is a brutal reminder that regulators don’t care whether your failure came from negligence or code drift.

They care that you didn’t catch it sooner.

When compliance automation fails, the legal question quickly becomes:

• Did you know it failed?

• Should you have known?

• And what governance model existed to find out?

If your only line of defense is “we trusted the dashboard,” congratulations, you’re one bad SQL query away from a headline.

What I’ve Seen (and You Probably Have Too)

I once joined a call where IT swore their monitoring system was “fully automated.”

I asked how they validated it.

They said, “The dashboard’s green.”

We pulled the data. The dashboard was green because the error handler failed silently for 47 days.

Our “continuous monitoring” was, in fact, continuously broken.

Lesson learned: Green doesn’t mean good. It means nobody’s checking.

What Coinbase Missed…and You Might Too

You don’t need to run a crypto exchange to fall into this trap. Coinbase’s failure could just as easily happen in your privacy, cybersecurity, sanctions, or AI governance stack.

Here’s what likely went wrong under the hood:

1. Model or rules drift: Someone tweaked the monitoring logic or schema, and certain transaction types fell outside the scope.

2. No change-control testing: Updates went straight to prod without regression checks.

3. No control assurance: Compliance relied on output summaries, not raw validation.

4. Poor board reporting: KPIs showed “transactions reviewed,” not “transactions unmonitored.”

5. No auto-alert for volume anomalies: A gap that big should’ve tripped alarms for data integrity.

Every one of these is common. None of them is “crypto-specific.”

Replace “transactions” with “data transfers,” “vendor queries,” or “AI model access logs,” and you’re staring at your own risk register.

What This Means for GCs

This case is a five-alarm fire for governance of automation.

We’ve spent years telling our companies to automate compliance.

Now we have to explain to our boards that automation can fail just as spectacularly, and much more quietly, than people.

Your new role: Be the person who asks “who’s checking the checker?”

That means:

• Embedding control assurance into every automated process.

• Setting a cadence for quarterly back-reviews (yes, even when “nothing’s wrong.”)

• Building cross-functional ownership: compliance writes the rules, IT enforces them, Legal audits the output.

• And documenting all of it, because “we thought it worked” isn’t going to cut it in a regulator meeting.

The GC’s “Monitoring Failure Playbook”

Here’s how to prevent your automation from turning into your next enforcement action:

1. Define control ownership clearly. Who owns the rule logic? Who signs off when it changes? I’ve seen companies where “everyone” owns it… which means no one does.

2. Establish pre-deployment testing. Every change to your monitoring logic should go through a test environment with seeded alerts. If your team rolls updates directly into production, you’re inviting ghosts into your data.

3. Implement drift detection. Code and data models evolve. Controls should alert when coverage drops or field mappings change.

4. Set a back-review schedule. Pick a period (monthly, quarterly) and re-run historic data to catch missed flags. It’s boring, but so is being fined €21.5 million.

5. Create escalation and reporting triggers. If anomalies spike or coverage dips, Legal should see it within 24 hours, not after the next quarterly ops review.

6. Maintain a “hotline for robots.” That is, a process for employees to report suspected control failures. Someone always notices something weird before the system does.

7. Make your dashboards human-readable. No one on the board cares about API call rates. They care about coverage percentage, missed alerts, and financial exposure.

8. Do a post-mortem before the regulator does. If something breaks, investigate immediately, document it, and fix it fast. Regulators will forgive an error. They won’t forgive silence.

The Metrics That Actually Matter

If your board deck still shows “# of alerts generated,” you should change it.

Here are metrics that help tell a story:

The Regulatory Subtext: Automation ≠ Accountability

The Coinbase decision is a turning point in how regulators view automation.

The subtext was clear: “You built the system. You’re responsible for knowing when it breaks.”

It’s the same logic we’re starting to see in AI governance and data security enforcement. If your algorithm or automation makes a compliance decision, the company owns the outcome—not the vendor, not the code, not the intern who pushed the update.

I expect to see more of this logic bleed into other enforcement areas:

• Privacy DPIAs that rely on automated tagging tools.

• Sanctions screening done by third-party models.

• HR systems auto-processing cross-border data.

If any of those fail quietly for months, expect regulators to say, “We’ve seen this movie before…and it ends in fines.”

The GC’s Role in “Invisible Failures”

To be honest: most GCs are not auditing code. But your job isn’t to be the engineer, it’s to ensure governance exists.

You don’t need to know how the regex works. You just need to know that someone’s checking that it still works.

Ask these five questions in every automation-heavy process review:

1. What triggers tell us a control has stopped working?

2. Who’s responsible for detecting those triggers?

3. When was the last time we manually validated the output?

4. How is this risk reported up to me or the board?

5. What’s our plan if it fails silently for a month?

If you don’t get a crisp answer, assume there isn’t one.

“But We Self-Reported!” The False Comfort

Coinbase did the right thing by self-reporting once they found the bug.

But self-reporting doesn’t erase three years of exposure. Regulators treat it as mitigation, not absolution.

I’ve seen this play out in other sectors:

• A fintech self-reported a failed sanctions screen. The regulator still fined them, but cut it in half.

• A SaaS company self-disclosed a data-retention gap. They escaped fines but were stuck under a 2-year compliance monitor.

So yes, disclose. But don’t expect a gold star.

The Real Cost

€21.5 million sounds painful, but the real cost wasn’t the fine, rather it was the remediation. Coinbase reportedly had to:

• Reprocess millions of transactions retroactively

• File 2,700 Suspicious Transaction Reports (STRs)

• Update internal monitoring logic and documentation

• Deal with months of regulator meetings

Add legal fees, consulting, reputational damage, and lost time, and the true cost likely hit eight figures.

And that’s before you count the operational drag of fixing controls under a microscope.

For every company that says, “we’ll cross that bridge when we get audited,” remember: by the time you’re crossing it, it’s already on fire.

What Every GC Should Do This Quarter

If you want a quick sanity check on whether your automation might be hiding a time bomb, start here:

• Ask your IT or compliance team to show you how they know their controls are working.

• Review any automated process that touches regulators, customers, or money.

• Add “control drift review” as a standing agenda item for your risk committee.

• Make sure your board reports focus on risk coverage, not just activity counts.

• And most importantly: establish a “we’d rather find it than hide it” culture.

You can’t fix what nobody’s looking for.

Final Thought: The Automation Illusion

Automation doesn’t remove human error, it industrializes it.

When something goes wrong in a manual process, you get a few bad entries.

When something goes wrong in an automated one, you get three years and €176 billion worth of “oops.”

Coinbase’s fine is a good wake-up call.

We’ve built legal and compliance programs on automation, AI, and dashboards that say “all clear.”

Now it’s time to add a new line to your risk matrix: Silent system failure: detected only when the regulator calls.

Subscribe now

Subscribe now

The AI Party Just Ran Out of Cash

You know that scrappy AI startup your marketing team swore was “transformational”? The one you negotiated a DPA with at 11 p.m. on a Tuesday?

You might want to check if they still exist.

Because 2025 is shaping up to be the year of the AI Vendor Collapse.

After two years of hype, hundreds of AI startups are finding that GPUs aren’t free, VC money has a half-life, and “monetizing inference” isn’t a business model…it’s a prayer.

A dozen smaller providers have already gone dark or been swallowed in quiet “acqui-hires.” And each time it happens, in-house legal teams are left wondering: “Wait…do we still own our data?”

Short answer: Maybe.

Long answer: Not if your vendor’s assets are now sitting in a bankruptcy estate labeled “miscellaneous training materials.”

1. How We Got Here

Training large models is like burning cash to boil the ocean.

Even a modest LLM takes tens of millions in compute and power. OpenAI, Google, Anthropic, and a few hyperscalers have the hardware. Everyone else rents it…and bleeds.

Many AI vendors signed enterprise pilots at “intro pricing” that barely covered their GPU bills. When venture funding slowed, those margins imploded.

I once reviewed a contract that promised “three-year data retention post-termination.” The company lasted fourteen months. They didn’t breach, they just evaporated.

2. The Legal Nightmares Nobody Budgeted For

When an AI vendor folds, three things vanish with them:

1. Your data. Prompt logs, fine-tuned models, embeddings, and outputs which are often hosted on their cloud, not yours.

2. Your IP. Anything you uploaded or co-trained may now sit inside a model the bankruptcy trustee can sell.

3. Your compliance posture. Your gorgeous DPIA, vendor assessment, and audit trail? Worthless if the vendor no longer exists.

A fintech company once reached out in panic: their text-analysis vendor went dark mid-quarter, taking six terabytes of training data with it. Their only copy was inside the model weights.

There’s no clause for that.

3. The Contract Illusion: “Perpetual Access” Isn’t Real

Most AI vendor agreements are recycled SaaS templates—subscription-based, “service as available,” termination at will.

That’s fine when you’re renting CRM software. It’s a disaster when your own data is baked into their model.

Typical language: “Upon termination, Customer may request deletion of data.”

Sure. If anyone’s still answering support tickets.

Once a company enters insolvency, your “service level agreement” becomes a suggestion written on a post-it in the data center.

4. What Happens in Bankruptcy (and Why It’s a Horror Show)

When a vendor files for bankruptcy, everything (e.g. models, datasets, source code, etc.) becomes part of the estate.

Trustee control: A court-appointed trustee decides what happens next.

Asset sale: Those LLMs and datasets can be auctioned to whoever offers the highest bid. (Yes, including your competitors.)

Access loss: APIs shut off overnight. Backups get encrypted. Support Slack channels go dark.

Data exposure: If your confidential data was used in training, it’s now mixed into an asset that might be sold.

I once got a call from IT asking if “the bankruptcy court” could just email us our data back…That’s not how any of this works.

5. The Hidden Cost: Operational Blackout

Most companies treat vendor loss like a procurement problem. It’s not. It’s a continuity crisis. When your AI provider folds:

• Integrations break.

• Reports fail.

• Your “AI-powered workflow” turns into “manual spreadsheet powered.”

One company’s support team discovered their summarization model was gone when the ticket queue doubled overnight. They thought it was a network outage. It was a liquidation.

6. How to Protect Yourself (While You Still Can)

Here’s where the GC earns the big bucks or at least avoids the 2 a.m. board call.

1. Escrow the model.

Treat fine-tuned weights and your training corpus like source code. Require a neutral third party (or your own cloud tenant) to hold copies updated quarterly.

2. Separate your data.

Ban “pooled” or “shared” training unless you’ve signed explicit rights to purge your slice. Your data should live in its own S3 bucket, not a shared soup of clients.

3. Add survivability clauses.

Draft language such as: “In the event of vendor insolvency, customer shall receive a perpetual, royalty-free license to continue using any models derived from customer data.”

Will every vendor agree? No. But the good ones will…and that’s the point.

4. Demand clarity on hosting.

If they’re running on AWS or Azure, require they identify the tenant, region, and data-retention defaults.

5. Keep a copy.

Even if it’s obfuscated or partial, maintain local exports of your fine-tuning datasets and output logs. “We thought they had backups” isn’t good enough.

When vendors balk, tell them you’ve seen too many “innovation partners” vanish mid-sentence. Watch them blink.

7. Insurance, Indemnity, and Other Fairy Tales

Ask your AI vendor about their insurance coverage.

You’ll usually get something like: “We have $1 million in cyber liability coverage.”

That’s adorable. That covers, maybe, one hour of your downtime.

Most indemnities exclude bankruptcy or “business failure.” And those that don’t are capped at total fees paid which, in a pilot, is lunch money.

Translation: When the music stops, your protection plan is a Spotify playlist.

8. If It’s Already Happened: The Triage Plan

If your vendor just went dark:

Step 1: Treat it as a breach.

Even if you’re not sure personal data was exposed, assume it could be. Start the legal notification clock.

Step 2: Contact the trustee (if one exists).

File as a creditor for any owed data-return rights. You’ll be somewhere behind AWS and the landlord, but at least you’re on the list.

Step 3: Contain the blast radius.

Identify which business processes used that vendor’s models. Replace or pause them immediately.

Step 4: Communicate clearly.

Executives hate surprises. Tell the board early: “Vendor insolvent, data inaccessible, mitigation underway.”

No one ever got fired for being the first to deliver bad news.

9. The Vendor-Diligence Upgrade

If you only take one thing from this article, let it be this: do vendor due diligence like your data depends on it.

Add questions that cover the following to your next AI vendor review:

1. Who actually owns the infrastructure?

2. Who owns the trained model and fine-tuned outputs?

3. What’s your cash runway? (Yes, you can ask.)

4. How do you segregate customer data during training?

5. What happens if you disappear?

I now ask vendors for a twelve-month cash-flow statement.

If they call it “overkill,” I call it “Tuesday.”

10. The Myth of Portability

Every AI vendor claims “your data is portable.” That’s like saying your sourdough starter is portable after it’s baked into 200 loaves of bread.

Once your text, code, or customer interactions are part of model weights, you can’t extract them cleanly. Even if you could, you might violate copyright or privacy laws trying.

So when you hear “portability,” read it as “good luck, and Godspeed.”

11. Building Redundancy: The GC’s Disaster Plan

Legal rarely owns disaster recovery but you’ll be in the hot seat when the disaster is legal and technical.

Build a redundancy plan:

• Two vendors minimum. Even if one is “experimental,” keep an alternate workflow tested and ready.

• Mirror critical data. Store fine-tuning inputs in your own environment, encrypted but retrievable.

• Set export triggers. Quarterly or semi-annual model exports written into the MSA.

• Have a kill-switch. Ensure IT can revoke API keys or tokens instantly if the vendor collapses or is acquired by a competitor.

Remember: the fastest way to test resilience is to simulate failure before it happens.

What This Means for the Boardroom

Boards love hearing about “AI innovation.” They’ll be less thrilled when the CFO says, “Our AI partner just disappeared and took our analytics pipeline with them.”

As GC, you need to translate this risk into numbers:

• What percentage of workflows depend on external AI vendors?

• What would a one-week outage cost?

• How much data is stored externally, and where?

Turn “vendor risk” into a financial line item. That’s how you get resources before the crisis.

One board chair told me, “I didn’t realize AI vendors could just go bankrupt.”

I said, “They’re startups. Of course they can. That’s their default setting.”

Lessons from the Shakeout

Every tech revolution has its hangover.

After dot-com came the hosting bust.

After fintech came the API implosions.

Now it’s AI’s turn.

This wave isn’t killing innovation. It’s killing under-capitalized infrastructure.

And that’s fine, if you planned for it.

The GCs who survive aren’t the ones who wrote the prettiest AI policy.

They’re the ones who quietly built backup plans, escrowed their models, and budgeted for the day the lights went out.

Because sooner or later, one will.

Final Thought: The Only Thing Worse Than Losing Data Is Finding It for Sale

AI isn’t going anywhere, but a lot of its vendors are.

When the next flashy startup folds, you don’t want to be the GC explaining to your CEO why “our proprietary dataset” just got listed as “miscellaneous training materials” in a liquidation auction.

The fix isn’t paranoia. It’s preparation: tight contracts, redundant vendors, escrowed models, and a healthy dose of skepticism.

Because in the AI gold rush, everyone’s digging, but not everyone makes it out of the mine.

And when the cave-in comes, Legal’s job isn’t to panic.

It’s to pull out the continuity plan, flip to the “Vendor Insolvency” tab, and say the four words every CEO loves to hear: “We planned for this.”

Subscribe now

Here’s something in the boardroom no one likes to say out loud: Europe is now the most expensive market in the world to stay compliant in…and that’s before you sell a single product.

According to a recent study commissioned by the Computer & Communications Industry Association, U.S. tech firms collectively bleed $39 billion to $97 billion every year in lost revenue, fines, and compliance overhead from EU digital regulation.

That’s not GDPR fines.

That’s not “oops we forgot a cookie banner.”

That’s the business cost (i.e. product redesigns, market withdrawals, slower launches, and data-flow surgery to keep servers on the right side of the Channel).

I see it firsthand. Companies initially thought they needed one privacy counsel for Europe. Now they need a standing army.

1. What’s Driving the Bill

If you’re wondering where the money goes, meet the culprits:

• Digital Markets Act (DMA): Limits how large platforms combine user data, forcing structural changes to core business models.

• Digital Services Act (DSA): Turns content moderation and algorithmic transparency into legal obligations, with audits.

• GDPR: The grandfather of compliance cost, still quietly eating budgets through Data Protection Impact Assessments and localization demands.

• Data Act & AI Act: Next-gen rules that add mandatory access-sharing, risk classifications, and algorithm transparency.

Each regulation has noble goals. Collectively, they’re a CFO’s migraine.

For one U.S. cloud vendor, complying with the DMA’s data-silo rule meant building a parallel architecture for EU clients (a $14 million rebuild) just to avoid cross-region data mixing.

For another, the DSA’s content rules triggered 24/7 human moderation.

Compliance payroll alone jumped 18 percent.

Multiply that across thousands of companies, and you hit the CCIA’s headline number fast.

2. Why Most Companies Underestimate It

Most GCs still treat EU regulation like a one-time legal project:

budget $500K, update governance documents, move on.

But there’s a hidden cost stack no one models correctly:

1. Compliance cost – the lawyers, consultants, and audits.

2. Engineering cost – rebuilding features to comply with DMA/DSA.

3. Opportunity cost – delayed launches or restricted functionality.

4. Revenue cost – customers lost because your EU product is worse than your U.S. one.

Example: a SaaS company I advised decided to hold off on its AI feature for EU users “until we have clarity.” That “clarity” took 14 months and cost them their first-mover advantage in Germany.

By the time they launched, a local competitor had filled the gap.

Regulation didn’t just cost them compliance dollars, it cost them market share.

3. The “Big Tech Only” Myth

You don’t need to be a gatekeeper to feel the squeeze.

The DMA technically targets companies with €75 billion + market caps, but its gravity pulls everyone into orbit.

If your app integrates with a gatekeeper, processes EU user data, or sells to EU customers, you’re touched by it.

A mid-size U.S. ad-tech company told me they assumed the DMA “doesn’t apply to us.” Then Google changed its API behavior under the new rules…and their core feature broke overnight.

They spent three months rebuilding and six months renegotiating client contracts.

An, yet, the DMA never mentioned them. They were just collateral damage.

4. The Cost Isn’t Just Legal. It’s Structural.

Regulation has officially jumped the fence from “legal” to “strategic.”

It’s now shaping how products are built, how data moves, and how revenue is recognized.

Take data localization:

• Every “store in the EU” clause means new servers, new vendors, new breach exposure.

• Every cross-border restriction means latency, downtime, and doubled infrastructure cost.

Or design neutrality:

• The DMA bans “self-preferencing,” so your own app store can’t highlight your app first.

• That change alone can shave single-digit percentages off conversion rates—millions in lost sales.

One global marketplace told me they had to redesign their ranking algorithm twice in six months, with lawyers sitting in sprint reviews. The head of product now jokes they’re “governed by Brussels by proxy.”

5. How These Costs Sneak Up on You

Unlike a fine, business costs don’t show up in one quarter. They bleed in slowly.

Here’s the typical timeline:

Month 1–3: Legal drafts the compliance roadmap.

Month 4–6: Product realizes three core features conflict with the DMA.

Month 7–9: Engineering requests new infrastructure.

Month 10–12: Finance discovers the EU P&L just shrank 15 percent.

By the time anyone adds up the true impact, it’s too late to pass the cost on to customers.

The CCIA study calls it “cumulative regulatory friction.” I call it death by a thousand consent banners.

6. What GCs Should Be Doing Now

If you’re the GC (or acting like one), here’s what your next steps should be:

1. Map exposure, not just applicability.

Don’t ask “does this law apply to us?” Ask “will someone we depend on change because of it?”

2. Quantify cost early.

Sit down with Finance. Estimate redesigns, audits, and market loss. Make it real.

3. Integrate Legal into product planning.

• European laws don’t wait for quarterly reviews. Be in the sprint.

4. Scenario plan.

What happens if your EU version must separate data or remove features? Price that scenario.

5. Track enforcement patterns.

Early DSA cases are showing regulators love precedent. If your competitor gets fined for it, assume you’re next.

7. The CFO Conversation Nobody Wants

One CFO told me, “Every time Europe passes a law, our margins drop two points.”

He wasn’t exaggerating.

Most companies absorb compliance costs instead of re-pricing. But when compliance hits product design, you can’t just “budget it out.” You either charge more, ship less, or lose speed.

It’s the regulatory equivalent of a carbon tax, except instead of emissions, you’re paying for complexity.

I’ve seen boards react two ways:

• The optimists: “We’ll turn compliance into a competitive advantage.”

• The realists: “We’ll try not to get crushed by the advantage someone else already has.”

Both end up writing checks to consultants either way.

8. What Makes This Moment Different

There’s a quiet shift happening: EU digital regulation is no longer about privacy, it’s rather about power.

Every rule now tweaks market structure, not just data handling. It’s about platform access, algorithmic control, and economic sovereignty.

For U.S. tech firms, that means compliance isn’t just expensive, it’s existential.

The CCIA report notes that for every €1 spent on legal compliance, companies lose another €3–€5 in opportunity cost.

That ratio explains why even giants like Meta and Apple are publicly grumbling. For smaller players, it’s a knockout punch disguised as red tape.

9. How to Survive the Europe Effect

You can’t escape EU regulation by staying out of the EU anymore.

The “Europe Effect” means global alignment by inertia—vendors, APIs, and customers all adapt to the strictest rule.

So if your partner or supplier complies, you’re already in scope.

What works in practice:

• Leverage your big partners’ compliance. Piggyback on AWS, Microsoft, or Google certifications where possible.

• Simplify documentation. The DSA and DMA may require public disclosures sp make them easy to update.

• Don’t over-lawyer. A 60-page “Regulatory Impact Framework” nobody reads is not strategy.

One client saved seven figures by adopting a “minimum viable compliance” model: they built a cross-functional triage board for EU issues. Every new rule was scored:

• Applies directly to us?

• Affects partner dependency?

• Potential revenue hit?

If it failed all three, it went to the “ignore until enforced” pile. Bold, yes—but efficient.

10. The Real Lesson: Compliance Is Now a Product Feature

For years, compliance was a box you checked after launch.

Now, it’s a competitive differentiator baked into product strategy.

Your customers care if you’re compliant.

Your investors assume you’re not.

And your regulators are actively testing that assumption.

The companies winning in Europe aren’t the ones with the biggest legal team but rather the ones where Legal, Product, and Engineering actually speak the same language.

Because let’s be honest: no one wants another “AI compliance steering committee.” They want someone who can say,

“If we launch this feature in France, it’ll cost €600K and three engineers for six months. Still worth it?”

That’s the new fluency of a modern GC.

Final Thought: The True Cost Isn’t Measured in Euros

The most expensive part of EU digital regulation isn’t the audit fees—it’s the drag.

It’s the slowed innovation, the split product roadmaps, the legal caution that kills creativity.

You don’t have to love Europe’s rules, but you do have to budget for them…and sooner rather than later.

The GCs who treat compliance like infrastructure (predictable, funded, maintained) will save millions.

The ones who treat it like a one-off project will find themselves on calls explaining why “market entry delay” became “missed market entirely.”

Because every new EU rule is a business model stress test.

And the price of failure isn’t a fine…it’s irrelevance.

Subscribe now

Subscribe now

Everyone Has a Policy. Nobody Knows What’s in It.

AI use policies are the new BYOD policies: written in a panic, circulated in Slack, and ignored by 40% of the company within 24 hours.

Right now, every company is racing to publish its “AI Use Policy.” Some call it “Responsible AI,” others call it “Acceptable Use,” but let’s be honest…most of them read like this:

Use your best judgment. Don’t break the law. Also, please don’t paste customer data into ChatGPT.

Legal writes it, comms posts it, IT enforces it (theoretically), and everyone prays it works.

But here’s the uncomfortable truth: your AI use policy is only as strong as the weakest Wi-Fi connection in your org. And the person most likely to break it isn’t malicious. It’s the intern trying to impress the VP by “automating” a report with public AI tools.

1. The False Sense of Safety

You know the drill. The board says, “Do we have an AI policy?”

You say, “Yes.”

Everyone breathes a sigh of relief. But nobody asks the next question: Does anyone follow it?

AI policies give executives comfort, not control. They’re like those “Caution: Wet Floor” signs. Legally protective, practically ignored.

I once reviewed an “AI Use Policy” that said, “Employees may not use AI for any company purpose unless authorized.”

They published it company-wide the same week they rolled out Microsoft Copilot.

Governance drama at its finest.

2. The Problem with “Don’t Paste Data”

Most AI use policies start and end with this sacred line: “Do not input confidential or personal data into AI systems.”

Sounds good. But what does that mean in practice?

• Is a customer name confidential?

• Is a contract summary personal data?

• Does “input” include API calls?

If Legal can’t explain it clearly, what chance does Marketing have?

A fellow GC shared, the engineering team proudly told him they had “segmented” data before using ChatGPT. he asked how. They said, “We changed the file names.”

That’s when he realized: AI use policies don’t fail because people are reckless, they fail because people are literal.

3. The Great Divide: Legal Writes, IT Enforces, Nobody Talks

AI policies are where good intentions go to die between Legal and IT.

Legal writes, “Employees shall not use unauthorized AI tools.”

IT says, “Define unauthorized.”

Legal says, “Anything not approved.”

IT says, “Nothing’s approved.”

End of meeting.

The result? Legal thinks it’s done its job. IT thinks Legal’s living in fantasyland.

And employees think the policy doesn’t apply to them because the VPN keeps disconnecting.

IT once found an AI prompt log titled “TOP SECRET” on a shared drive. The “secret”? A company strategy doc copy-pasted into ChatGPT. When I asked who did it, the team said, “The policy didn’t say we couldn’t use free accounts.”

4. The Wild West of “Approved Tools”

Every company now has a list of “approved AI tools.” It’s usually two things: Microsoft Copilot and “whatever Security hasn’t noticed yet.”

I’ve seen entire departments operating on rogue APIs, open-source models, and Chrome extensions. The policy said “only approved tools,” but nobody kept the list current.

One company had an “approved tools” spreadsheet last updated in May 2023.

When checked, two of the tools had been acquired and one was shut down.

The CTO said, “We thought Security was maintaining it.”

Security said, “We thought IT was.”

Legal said, “Cool, so…nobody?”

5. Shadow AI: The Real Threat

Forget external risk. Shadow AI is the real enemy.

That’s the data scientist using OpenAI API keys from their personal account.

The marketing intern who “tried a free summarizer.”

The executive who asked Gemini to rewrite a board email “for tone.”

Your AI use policy doesn’t stop them.

At best, it gives you moral high ground when things go wrong.

I once discovered a “pilot AI project” that had been running for four months. It was ingesting customer data through a third-party tool. The VP proudly said, “Don’t worry. It’s internal.”

I thought, “So was the Titanic.”

6. Why This Is Basically a Trust Fall with IT

Here’s the truth nobody admits: AI governance at most companies is 60% trust, 30% security controls, and 10% wishful thinking.

You’re trusting IT to:

• Detect rogue AI use.

• Enforce access controls.

• Review vendor models.

• Stop anyone from connecting public APIs to internal data lakes.

And you’re trusting employees to:

• Read your 12+ page policy.

• Understand it.

• And not paste next quarter’s roadmap into a chatbot on their phone.

That’s not governance. It’s a trust fallwith IT standing there holding a coffee cup, saying, “Wait, are you falling now?”

7. How to Make It Actually Work (Sort Of)

AI use policies aren’t useless, they’re just lonely. Pair them with actual process:

1. Create an approved tools list that lives somewhere real.

   • Not a PDF. A living doc in your internal wiki.

   • Assign ownership (hint: not Legal).

2. Add logging and detection.

   • If your IT team can block TikTok, they can monitor AI traffic.

   • Legal doesn’t need visibility into every prompt, just know who’s experimenting.

3. Define “sensitive data” in plain English.

   • Employees won’t protect what they don’t understand.

   • Example: “If you wouldn’t email it to an external vendor, don’t paste it into AI.”

4. Train your people like it’s phishing.

   • Repetition beats complexity.

   • 5-minute refreshers every quarter do more than a 45-minute-long annual training ever will.

5. Align Legal, Security, and IT.

   • Hold monthly syncs. Bring snacks. It’ll feel like couples therapy, but it works.

8. The Smart Way to Evolve Your Policy

The best AI use policies are iterative. Treat them like code:

• Ship version 1.

• Test it.

• Patch what breaks.

Start simple: “Use approved tools. Don’t input sensitive data. Ask before you automate.”

Then add: “If in doubt, email AI-review@company.com.”

By version 3, you’ll have a policy people actually follow and not because they fear it, but because they helped shape it.

I once saw a company crowdsource policy feedback from employees. They found 70% of confusion came from just two words: “personal data.” After they clarified it, violations dropped by half.

Turns out, the problem wasn’t compliance. It was communication.

9. Reporting Like a Pro (and Staying Out of Trouble)

Executives don’t want to hear “policy violations.” They want trends.

Say:

• “Five AI incidents this quarter. Three from unapproved tools. Two from training data issues.”

• “Remediation: awareness training, logging, and access controls added.”

Show that Legal’s not just wagging a finger, it’s building muscle memory.

One board member told me, “I finally understand our AI policy. It’s like cybersecurity 10 years ago…all trust until it breaks.”

Exactly. Except this time, maybe we get ahead of it.

10. Governance Is the New Faith

Let’s be honest, AI use policies are acts of faith. You can write rules, hold trainings, and add banners that say “Don’t share sensitive data,” but at some point, you’re trusting humans.

And humans?

They’re curious, busy, and occasionally overconfident.

So make your AI use policy simple enough to remember, flexible enough to evolve, and real enough that IT doesn’t roll their eyes when you mention it.

You’ll never stop every rogue API key or ChatGPT copy-paste. But you can build a culture where people pause before they hit enter…and that’s half the battle.

Until then, every AI policy is a trust fall.

The trick is making sure IT’s actually standing there to catch you.

Subscribe now

Subscribe now

Everyone Wants an AI Policy, No One Wants to Read It

Every company right now wants to say they have “Responsible AI.”

Few can define it.

Somewhere between the engineers saying “It’s just math!” and the board saying “Are we at risk?” sits Legal—trying to design guardrails that don’t sound like a science fair project or a philosophy paper.

Most GCs start with good intentions. They open a blank Word doc titled “AI Governance Policy v1” and think, this time, it’ll be practical.

Three weeks later, they have a 40-page epic quoting NIST, the EU AI Act, and every ethics principle known to humankind.

It’s beautiful. It’s also unread.

AI governance doesn’t need to be complicated. It needs to be clear, fast, and boring enough that people actually follow it.

The Myth of the Big Policy

Every AI governance journey starts with someone saying, “We need a policy.”

And that’s where the trouble begins.

You don’t need a 40-page policy. You need a 4-page playbook that says:

1. What people can and can’t do.

2. Who to tell before they do it.

3. What happens if they ignore that step.

That’s it.

I once had a lawyer write a Responsible AI policy that was longer than our privacy standard. It covered every risk scenario: bias, explainability, accountability, transparency. It had citations, footnotes, and a glossary.

Nobody read it.

When we finally replaced it with a one-pager titled “AI Guardrails for Humans Who Just Want to Ship Stuff,” people actually followed it.

Because here’s the thing:

If your AI policy needs a training session to explain it, it’s never going to work.

10 Steps For AI Governance Policies

1. Know What You’re Governing

“AI” isn’t one thing. It’s a grab bag of magic tricks that all get labeled “AI” when someone in marketing thinks it’ll sound smart.

If you want your governance framework to work, start by splitting your world into two lanes:

• AI-For: internal use of AI tools (ChatGPT, CoCounsel, internal copilots).

• AI-On: AI that is your product or feature (customer-facing).

Different risks. Different rules.

When an employee uses ChatGPT to summarize an NDA, that’s an AI-For use case.

When your SaaS product uses AI to summarize a customer’s data for them, that’s AI-On. And regulators care a lot more about the second one.

I’ve seen companies apply the same policy to both and then wonder why everyone ignores it. The marketing team trying to use an image generator doesn’t need a model governance committee. They just need to know not to upload customer data.

If you can’t tell the difference between AI-on and AI-for, your first governance step is figuring that out…fast.

2. Build a Lightweight Review Process

AI governance fails when your review process moves slower than your engineers.

You don’t need a formal “AI Review Board” that meets once a quarter and produces PowerPoints nobody reads. You need an intake process that people actually use.

Here’s a good rule:

If your AI intake form takes longer to fill out than it takes to build the tool, you’ve messed up.

At one company, we built our intake in SharePoint. Not glamorous, but it worked.

We asked four basic things:

1. What’s the use case?

2. What data does it touch?

3. Who’s responsible if it breaks?

4. Is there any chance this ends up on the front page of the Wall Street Journal?

That last one was our “gut check.”

And it worked. We caught a project that was quietly training on customer data before it reached production.

AI governance doesn’t need to be fancy. It needs to be fast.

3. Classify the Risk. Then Move.

Not all AI is created equal. You don’t need to put the same guardrails around an internal chatbot that you do around a hiring algorithm.

I use a simple triage model:

• Low risk: Productivity tools, copilots, or anything that uses public or anonymized data.

• Medium risk: Tools trained on internal non-sensitive data.

• High risk: Anything that touches personal data, customer systems, or decision-making.

For each, define what’s needed:

• Low = quick review.

• Medium = legal + security check.

• High = full risk assessment + leadership sign-off.

One engineer once asked me, “So red means bad?”

No…red means “we’re showing up early.”

A matrix works better than a manifesto. Boards love heat maps. So do execs. And if your governance model fits on one slide, you’ll likely get it adopted.

4. Borrow From What Already Works

Don’t reinvent governance. Repurpose it.

Your company already has frameworks for privacy, security, compliance, and ethics. Use them. Add one AI line to each:

“If AI touches this data, automates this process, or influences this decision, Legal must review before deployment.”

That’s 80% of your policy right there.

We discovered that more than half of our “AI governance controls” were already covered by privacy, ethics, or security standards. So we deleted the duplicates. Suddenly everyone loved our new policy.

AI doesn’t need its own religion.

It just needs better ushers.

5. Assign Accountability (Not Ownership)

The worst line in any policy: “Legal owns AI governance.”

No. Legal facilitates it. Legal guards the perimeter. But AI risk belongs to everyone who builds or uses it.

Here’s how it really works:

• Product owns the design.

• Engineering owns implementation.

• Security owns data protection.

• Legal owns the panic button.

I once told an executive, “We don’t own the models. We own the mess if you ship one without telling us.” That stuck.

Think of Legal as the air traffic controller—coordinating, not piloting.

6. Make It Visible

AI governance fails in the shadows. You need visibility.

Build an AI registry: a single list of all approved tools, models, and use cases.

Track:

• Who owns it.

• What data it touches.

• When it was last reviewed.

We built ours in Power BI. Engineers mocked it, until they realized they were building duplicate models for the same feature.

Now they love it.

Nothing says “governance win” like engineers voluntarily checking your dashboard.

7. Don’t Forget the Humans

The best AI policy in the world won’t stop Carl in sales from pasting customer data into ChatGPT unless Carl understands why that’s bad.

Training beats policy every time.

You don’t need a lecture. You need a 5-minute video or a one-pager that says:

• Don’t paste confidential data into public AI tools.

• Don’t believe everything the bot tells you.

• Call Legal before you launch anything that looks like magic.

We added a five-minute “AI sanity check” to onboarding. It cost nothing.

Within two weeks, someone caught a prompt-injection issue in a pilot chatbot.

That’s governance in action, human plus habit.

8. Report Like the Board Actually Cares

Boards don’t want technical deep dives. They want assurance and trends.

Use the language they speak:

• “5 AI use cases reviewed this quarter.”

• “2 flagged for privacy risk, 1 for ethics.”

• “0 incidents, 1 new control implemented.”

One time, our quarterly report was literally a pie chart: “AI risk exposure by category.” The Audit Chair said, “This is the first AI report I’ve actually understood.”

That’s the goal. Don’t show off your governance IQ. Show your risk visibility.

9. Build for Change

The only thing moving faster than AI is AI regulation.

EU AI Act, Brazil’s AI Bill, the U.S. Executive Order…everyone’s building the plane midair.

Don’t hard-code policy to today’s rules.

Build principles that can flex tomorrow.

Ours boiled down to four:

1. Transparency

2. Accountability

3. Privacy

4. Human oversight

That’s it. Everything else plugs into those pillars.

If your policy needs a rewrite every time the EU updates a footnote, it’s not governance, it’s job security for lawyers.

10. Make It Useful, or It Dies

AI governance isn’t compliance theater. It’s survival strategy.

A good framework does three things:

1. Catches real risk early.

2. Doesn’t kill innovation.

3. Makes Legal look like a partner, not a bottleneck.

If your engineers say “Legal actually helped,” congratulations, you’re ahead of 90% of companies.

I once had an exec tell me after an AI review meeting, “That was the least painful governance discussion we’ve ever had.”

That’s how you know it’s working.

Because AI governance isn’t about stopping the work.

It’s about making sure nobody ends up on the wrong side of a headline.

Final Thought: The Best AI Policy Is the One People Use

AI governance should be simple enough for humans, strong enough for regulators, and fast enough for engineers.

You don’t need a manifesto. You need a map.

So keep it short. Keep it real.

And when someone asks for your 40-page policy, smile and say,

“We traded that for a 4-step process that actually works.”

The lawyers who get this right aren’t writing essays. They’re shaping how AI gets built—safely, transparently, and without becoming the “Department of No.”

And honestly, that’s the best kind of legal innovation there is.

Subscribe now

Subscribe now

The Problem: Everyone Wants to Be “AI-Powered”

Every legal department has that one exec who comes back from a conference and says, “We should be using AI for contracts.”

Great. Because nothing says efficiency like a chatbot that confidently redlines indemnities into oblivion or suggests deleting your entire limitation of liability clause “for readability.”

I’ve sat in more than a few of those meetings. The vendor deck starts with “transform your legal function” and ends with me asking, “But where does this plug into Outlook?”

AI in legal is having its hype moment. But after the headlines fade, what’s left is a mix of solid wins, a few hilarious failures, and a lot of tools still in search of a use case.

So let’s separate the hype from the help. Here’s where AI actually works today, and where it absolutely doesn’t.

1. Contract Review & Triage: The Workhorse (When You Keep It on a Leash)

If you’re reviewing 500 NDAs a month, AI can be your new best friend. Clause extraction, issue tagging, and prioritization…AI eats that for breakfast.

I once tested a tool on 400 vendor contracts. It flagged every clause mentioning “data,” which meant it highlighted every clause. We fixed the model, taught it context, and suddenly we were flying.

What AI does well:

• Sorts contracts by type, counterparty, or risk profile.

• Identifies missing clauses (“no indemnity found” = actual value).

• Speeds up review by handling the boring bits.

Where it fails:

• Subtle judgment calls. It can’t tell when a “minor” indemnity tweak could cost you $3M later.

• Context. It doesn’t know your company’s risk tolerance…or that “standard terms” are only standard until your CFO explodes.

AI is great for triage, not trust. Think of it as your paralegal with perfect recall and no instincts.

2. Intake & Ticket Routing: Surprisingly Useful (and Weirdly Underused)

If your lawyers spend 40% of their day forwarding emails, congratulations, you’ve built a help desk. AI can actually fix that.

We deployed an intake bot that categorized requests (“contract,” “employment,” “regulator panic,” etc.) and auto-assigned them to the right person. Within two weeks, our response time dropped by half.

Then we realized it was routing every message with “urgent” in the subject line straight to me. Including ones that said, “Not urgent.”

Lesson learned: AI can triage. You just have to teach it sarcasm.

Still, this is one of the lowest-risk, highest-reward uses. It saves time, enforces process, and makes Legal look organized..something we all deserve on our performance reviews.

3. Legal Research: Better Than Expected, Worse Than Marketed

AI research tools are like enthusiastic first-year associates: fast, confident, and occasionally wrong in ways that make you question your life choices.

They’re brilliant for summarizing laws, synthesizing trends, or giving you a first pass at “what this means.”

But:

• They hallucinate citations.

• They mix jurisdictions.

• They once told me the FTC fined a company for “insufficient cookie banners” in 1997.

Use AI to speed up your thinking, not replace it. I love asking: “Explain this new regulation like I’m briefing a CEO in five bullets.” That’s gold.

Just don’t ask it to “find precedent.” It will happily invent one and attribute it to a court that doesn’t exist.

4. Risk Mapping: The Pretty Pictures Department

Risk mapping with AI sounds sexy, until you realize it’s mostly data wrangling with better graphics.

It can absolutely help visualize where your compliance controls overlap or where your weak spots live. Feed it enough assessments, contracts, and audit reports, and it’ll show you clusters of recurring issues like a heat map of your stress levels.

One client used it to analyze five years of vendor reviews. The result: a gorgeous chart proving that everyone ignores data retention. No one was surprised. But now the board presentation had colors, and that made it real.

AI can highlight risk. It can’t prioritize it. That’s your job. Otherwise, you’ll end up with a rainbow chart of equal panic.

5. Drafting and Redlining: The Illusion of Progress

Every vendor promises “AI-powered drafting.” Most of it is just a fancy autocomplete.

Yes, AI can draft a halfway decent NDA. It can even redline for obvious gaps. But once you move past standard terms into real negotiations, it starts hallucinating confidence.

I tested one tool that “optimized” a master services agreement by deleting the indemnity clause and marking it “redundant.” It wasn’t redundant. It was my career.

For internal use, though? Gold. It drafts playbooks, standard clauses, and even policy updates faster than a committee email chain. I once had it generate a first draft of a Bring Your Own Device policy. Was it good? No. But it saved me two hours of starting from scratch, and two existential crises.

6. Compliance & Policy Drafting: Still Needs a Human Brain (and Tone)

AI can generate templates, but it can’t capture nuance. Ask it for a global data policy, and it’ll give you a word salad of “whereas” and “in accordance with.”

Ask it for something readable by employees, and it panics. I once got a version of a whistleblower policy that included the phrase “in case of egregious shenanigans.” Accurate, yes. Usable? Not so much.

That said, it’s a fantastic brainstorming partner. It can help you organize complex topics or explain them in different tones, like, “say this like a compliance trainer who’s had three coffees and one breakdown.”

AI helps you write faster. It won’t make you write better. That’s still your superpower.

7. Litigation & Investigation Support: Proceed With Caution

This one’s tricky. AI can summarize depositions, generate timelines, and identify key facts faster than paralegals armed with espresso.

But eDiscovery? Proceed carefully. AI-based predictive coding is great when trained on your data by humans who know context. Unsupervised tools? Recipe for privileged material accidentally hitting opposing counsel.

I once saw an AI review tag “employee misconduct” emails as “marketing opportunities.” That was a fun 48 hours.

AI in litigation support saves enormous time, but it needs governance like your career depends on it. Because it does.

8. The Real Barriers (and They’re Not What You Think)

The biggest blockers aren’t legal. They’re cultural.

• IT says: “We can’t approve this; it’s cloud-based.”

• Security says: “We can’t use this; it’s AI.”

• Finance says: “We can’t afford this; Legal’s a cost center.”

• Legal says: “We’ll just keep doing it manually but complain more.”

Implementation is the hardest part. The tech isn’t magic, it’s plumbing. If your contract process is chaos today, automating it just gives you faster chaos.

I once watched a team install an AI contract tool before agreeing on naming conventions. Six months later, they had “Final,” “Final_2,” and “Final_2_REAL_FINAL.” But now it was automated. Progress? Questionable.

9. What Actually Works Today

• Contract triage and risk tagging – saves hours, reduces human fatigue.

• Intake routing – instant wins in responsiveness.

• Knowledge summarization – perfect for prepping board or exec briefings.

• First-draft policy writing – get 60% done, then humanize it.

• Legal research acceleration – only if validated.

AI is great at what lawyers hate: repetition, formatting, and summarization. It’s terrible at what lawyers get paid for: judgment, context, and knowing when to say “no.”

My personal rule: if the task makes you want to switch careers to goat farming, it’s a good candidate for AI.

10. What Doesn’t (Yet)

• Redlining bespoke deals – nuance is still a human monopoly.

• Predicting regulator behavior – good luck modeling chaos.

• Building arguments – persuasive writing requires empathy and caffeine.

• Understanding internal politics – no algorithm can decode “per my last email.”

I once asked an AI what to tell our CFO after a data breach. It suggested: “Assure stakeholders the issue is minor.” It wasn’t. AI doesn’t do damage control.

11. Measuring Success (Because “It Works” Isn’t Enough)

If you’re rolling out AI in Legal, you need metrics that matter:

• Time saved per request or review.

• Reduction in outside counsel spend.

• Faster response time to the business.

And yes, accuracy still counts. If your AI tool drafts 100 NDAs but misses the indemnity clause in three, congratulations, you just created 3 future disputes.

I once had an executive ask, “How do we know if the AI’s right?” I said, “Same way you know if your lawyers are right…you find out in court.” We bought insurance instead.

12. The Culture Shift: AI Won’t Replace You (But It Might Promote You)

The legal teams that thrive in this new phase aren’t the ones that resist automation—they’re the ones that harness it for strategy.

AI won’t replace lawyers. But lawyers who use AI will replace those who don’t. The GC who can show time saved, risk reduced, and insights generated? That’s the one the CEO calls “business partner,” not “cost center.”

And if nothing else, you’ll finally have time to do the work you’re actually paid for instead of formatting Excel logs at 11:47 PM.

Final Thought: AI Isn’t Coming for Your Job, It’s Coming for Your Inbox

The future of Legal isn’t about replacing judgment; it’s about scaling it.

AI can handle the grunt work, the pattern matching, the mind-numbing contract reviews. But it can’t stand in front of a board and explain why something matters…or decide which risk is worth taking.

That’s still your lane.

So test the tools. Pilot the platforms. Laugh at the hallucinations. But don’t ignore the shift.

Because in five years, “we don’t use AI” will sound a lot like “we still fax contracts.”

And if you’ve ever lived through that kind of technological regression, you know: once was enough.

Subscribe now

Legal AI Meme of the Week

If you’re a GC or senior in-house lawyer, your job isn’t just to protect the company; it’s also to make sure the board knows what matters, why it matters, and what they need to do about it.

But board materials are a language of their own. They’re not memos. They’re not briefs. And they’re definitely not law review articles. If your board packet is filled with passive voice, five-syllable words, or risk lists with no story, it’s going to get skimmed, and you’re going to lose your moment.

I’ve learned (the hard way) that if you want your legal voice to land in the boardroom, you need to be sharp, strategic, and crystal clear. Here’s how to approach each key type of board material:

Subscribe now

1. Board Update Decks: Speak Strategy, Not Statutes

Boards don’t care about legal nuance. They care about whether Legal sees the forest and not just the trees. Your legal deck should answer one question above all: What does this mean for the business?

The best legal decks:

• Use headlines, not paragraphs

• Lead with strategy, not statutes

• Include 2–3 slides max unless you’re defending a merger

Example Slide:

• Title: “New EU AI Law May Delay Q4 Product Launch”

• Bullets:

  • Prohibited use flagged in current feature

  • Internal audit and mitigation plan underway

  • Recommendation: Delay rollout 30 days to avoid compliance risk

Avoid this: “The AI Act requires providers to ensure conformity with applicable obligations set forth under Articles 5–17.” (Yawn.)

GC confession: My first board deck had a slide titled “Recent Developments in Cross-Border Frameworks.” Nobody asked a single question. The CFO later told me it sounded like a travel brochure. And he wasn’t wrong.

2. Board Pre-Reads and Memos: Frame or Be Framed

If you’re sending materials before the meeting, do not make the board do interpretive work. Pre-reads are your opportunity to:

• Frame the issue

• Set the tone

• Define success

Keep it under 2 pages. Use subheadings and bullets. Lead with a summary paragraph:

“This memo outlines recent SEC developments impacting our incident disclosure process. If adopted, we recommend updating our internal playbook to reflect a 96-hour response window and notifying key functional teams.”

This is not the place for a 12-page memo filled with caveats. The board isn’t deciding how you interpret a regulation. They’re deciding whether the business is protected.

True story: I once sent a pre-read about a patent acquisition dispute that included a footnoted timeline of procedural history going back to 2007. The board chair’s comment? “I fell asleep three times reading this…and that was just the first page.” Brutal, but fair.

Also: write these early. If the board sees your issue framed first by the CFO’s deck, you’re already behind.

3. Board Resolutions: Keep It Tight, Clear, and Actionable

Board resolutions are legal records of corporate will. They should be accurate, actionable, and easy to understand, even for a sleepy director on slide 48.

Structure matters:

• Use “Whereas” clauses to set context

• Use “Resolved” clauses to state the actual decision

• Keep each “Resolved” focused on a single action

Example: Resolved, that the Company is authorized to enter into the Data Processing Agreement with Vendor X in substantially the form presented, subject to final legal review

Other tips:

• Include fallback options (e.g., “…subject to CFO and GC approval of final terms.”)

• Avoid overloading resolutions with too much narrative

Lesson from the field: During an employment misclassification crisis, I once submitted a resolution that tried to summarize the entire legal strategy in the “Whereas” clauses. One director called it “the War and Peace of worker status.” From then on, I stuck to the facts…and the short version.

4. Board Minutes: Don’t Make Yourself a Star Witness

Board minutes are not:

• A verbatim transcript

• A place to editorialize

• Your chance to prove you’re a good writer

They are a legal record of:

• What was discussed

• What decisions were made

• Who was present and voting

• Any follow-ups or resolutions

Golden rule: Assume they’ll be Exhibit A in litigation. Keep it factual and neutral.

Good minute: “The Board discussed potential risk exposure associated with cross-border data transfers. The GC summarized recent enforcement trends and proposed a mitigation plan. No action was taken.”

Bad minute: “The GC passionately argued that our privacy posture is insufficient and may lead to reputational damage.”

Been there: Once, I described a boardroom debate over IP ownership in an M&A deal as “tense but ultimately resolved.” Guess what showed up in due diligence six months later? That sentence. Lesson: write like opposing counsel will read it and highlight it.

5. Post-Meeting Summaries and Follow-Ups: Be the One Who Closes the Loop

After every board meeting, there’s usually a short list of legal to-dos. Don’t wait for someone else to chase you down. Send a recap note to the Board Chair, CEO, or relevant committee lead.

Include:

• What was asked of Legal

• What’s been done since

• What’s in flight or planned

Example: “Following the Board’s request at the July meeting, Legal completed an external review of our DPA template. Key recommendations have been incorporated. Updated version included in Q4 board packet.”

My moment of glory: After a board debate over IP indemnities in a vendor deal, I followed up with a crisp summary of our fallback positions, redline status, and next steps. The Chair forwarded it with a note: “This is how every exec should follow up.” I printed it out and taped it to my monitor.

6. Special Reports (Investigations, Breaches, Litigation): Tell the Truth, Tightly

Sometimes, Legal has to own the full spotlight…especially when things go sideways. A good special report should:

• Be fact-focused, not speculative

• Lay out a timeline

• Clarify what’s known, what’s not, and what’s being done

Structure:

1. Summary — One paragraph max

2. Timeline — Key dates, especially first detection

3. Current Posture — Internal and external

4. Mitigation Plan — What’s underway

5. Recommended Action — For the board or executive team

GC tip: Include a visual (timeline, heatmap, etc.). Boards love pictures that replace five paragraphs.

Personal panic: During a messy internal investigation into a terminated exec’s misuse of funds, I sent a report that casually said, “We’re evaluating potential clawbacks.” A director replied, “So we’re suing the guy?” I learned that legal nuance doesn’t travel well without caveats, context, and a plan.

7. Metrics That Matter: Use Numbers to Speak Strategy

Legal is often seen as a cost center. One way to combat that? Show metrics that tie to value.

Avoid vanity numbers like “pages reviewed.” Instead, try:

• Time-to-sign for high-value deals — Did Legal help close faster?

• Escalations resolved before litigation — Are we preventing fire drills?

• Regulatory inquiries closed with no finding — Are we keeping us out of the headlines?

• Average time to resolve internal investigations — Are we moving fast with care?

• IP assignments completed pre-funding — Are we protecting value pre-due diligence?

And always include a short narrative: “This quarter, Legal reduced average time to sign top-tier deals by 4 days which helped Sales recognize $6M in revenue early.”

GC fail: Once, I proudly included “Number of employee handbook reviews completed.” A director asked, “So…you like paperwork?” We cut that line.

8. Bonus: Read the Room, Not Just the Law

Sometimes your best board material is a few sentences, spoken clearly, at the right time.

I once had a Chair stop me mid-slide and say, “Can you just tell me if we’re going to get sued?” I put the clicker down and gave a real answer: “Not likely, but we’re treating it like yes until we close this gap.”

That got me more credibility than the 6-slide deck I was about to launch.

Final Thought: You’re Not Just a Lawyer in That Room

When you write for the board, you’re not documenting legal nuance. You’re shaping perception, enabling decisions, and building trust.

Your board materials aren’t just information, they’re signals. They tell the board whether Legal is strategic, in control, and focused on what matters.

So write like it matters. Because it does.

Subscribe now

It’s official…the final rule for the Cybersecurity Maturity Model Certification (CMMC) is landing on November 10, 2025. No more maybes. No more “let’s wait and see.” If you’re a defense contractor or anywhere near the Defense Industrial Base (DIB), it’s go time.

Contractors are currently split into three camps:

• Camp A: “We’ve been preparing for years. We’re ready.” (These people are lying. Or consultants.)

• Camp B: “We’ve heard of CMMC but thought it was optional?”

• Camp C: “We have a spreadsheet. It’s…somewhere.”

If you’re in Camp B or C, buckle up. This isn’t just another compliance checkbox. It’s a contract gate. And the DoD is serious this time.

Wait, What’s Actually Happening?

In December 2023, the DoD issued a Notice of Proposed Rulemaking (NPRM) to formalize CMMC. In plain English: they’re replacing the old self-attestation model with real audits, real teeth, and real consequences.

Here’s what’s in the final rule:

• CMMC Level 2 will require a third-party audit (via a C3PAO) if you touch Controlled Unclassified Information (CUI)

• Contract eligibility will be tied to certification—no certification, no contract

• Applies to primes AND subs. If CUI touches your systems, you’re in scope

There’s a 3-year phased rollout, but don’t let that lull you into a false sense of security. You don’t want to be the company scrambling to book an auditor 60 days before your bid is due.

And yes, I’ve seen that happen. The quote came back at $85,000. The CFO said “we’ll revisit next quarter.” The prime moved on without them.

The Real-World Stuff You Should Actually Care About

1. You Might Need to Pay for an Audit…Soon

If you’re handling CUI, a C3PAO audit is coming your way. These aren’t cheap. Current ballpark:

• Small business with straightforward systems: $30,000–$50,000

• Mid-size org with complexity or hybrid cloud: $70,000–$100,000

• Chaos goblin IT environment with no documentation: priceless (but still $100K+)

And that’s just the audit. It doesn’t count the cost of actually fixing gaps. Like the company I worked with last year that discovered they were missing 41 of 110 NIST 800-171 controls. Their IT lead said, “We’re working on it.” That was six months ago. They still haven’t scheduled their audit.

Pro Tip: Budget now. Also, assume your subcontractors are not ready. If you’re a prime, you might want to start screening your supply chain before someone else does.

2. You Can’t Fake the Paperwork Anymore

Security controls are one thing. Documented, implemented, and provable security controls? That’s the new bar.

If your System Security Plan (SSP) is just a printout of NIST 800-171 with checkboxes next to each control and the words “planned” scribbled in pencil—you’re in trouble.

You’ll need:

• System Security Plan (SSP)

• Plan of Action and Milestones (POA&M)

• Evidence. Logs. Screenshots. Configurations.

I once had a client whose SSP listed MFA as implemented, but during a readiness check, the only place MFA was enforced was on the CIO’s laptop. The auditors were…not impressed.

Auditors have one job: to find out if what you claim is actually true. Not what you hope is true. Not what you might someday fix. The truth, with documentation.

3. You Could Lose Bids If You’re Not Certified

This is the big one: you can’t win contracts if you’re not certified. The CMMC requirement will be a hard gate.

Even now, we’re seeing solicitations and primes adding language like: “All subcontractors must be CMMC Level 2 certified at the time of award.”

Not “working on it.” Not “scheduled for Q2.”

I’ve worked with companies that had to scramble at the last minute, trying to find “certified” partners to fill gaps. One told me, “We lost a contract we’ve held for 10 years because we couldn’t get an audit done in time.” Brutal.

And if you think your prime will make exceptions because you’ve “always been great,” think again. They’re not going to risk a bid because you didn’t get your house in order.

What About the Timeline?

Here’s the current rollout plan, per the final rule:

• November 10, 2025: Final rule goes live

• Year 1 (2026): Level 1 self-assessments required on certain contracts

• Year 2 (2027): Level 2 certifications required for some awards

• Year 3 (2028): Broad application across all eligible contracts

But you need to note: Level 2 certifications require 6–12 months of prep if you’re not already airtight. Booking an auditor alone can take months due to backlog.

So if you wait until the requirement is in your contract, it’s already too late.

This Isn’t Just About IT

One of the biggest myths? “This is an IT problem.”

Nope. CMMC touches:

• HR (background checks, training logs)

• Facilities (physical access controls, badge logs)

• Procurement (vendor risk management)

• Legal (contracts, flowdowns, representations)

• Finance (budgeting for security and compliance)

If you don’t have cross-functional alignment, you’ll fail. I once had a client whose IT team built a secure enclave…but no one told HR to update the onboarding process. A temp got provisioned with local admin rights and no training. Whoops.

Don’t Count on Your MSP to Save You

Managed service providers (MSPs) are helpful, but they can’t do everything.

Your MSP might:

• Configure your firewalls

• Help you deploy endpoint protection

• Run vulnerability scans

But they can’t:

• Write your policies

• Sign off on internal training

• Control physical access to your buildings

• Prove who accessed what and when

We had a client where the MSP promised “turnkey CMMC readiness.” We reviewed their evidence package. It was 12 screenshots and a link to a Microsoft blog post. That MSP is no longer on the roster.

Compliance Theater vs. Reality

You know what doesn’t count as compliance?

• A Google Doc titled “CMMC Plan” with no updates since 2022

• A Jira ticket that says “Audit TBD” with no owner

• Telling the auditor “we’ve got that under control” with no documentation

I’ve seen them all. One org printed out every control and wrote “Y” next to each. When I asked for implementation evidence, they said, “Well, we have antivirus.”

CMMC doesn’t care about your intentions. It cares about proof.

If You’re a Subcontractor, You’re in the Blast Radius

You don’t need a prime contract to be in scope. If you touch, store, process, or create CUI, you’re on the hook.

And primes aren’t waiting:

• They’re vetting their supply chains

• They’re dropping non-compliant subs

• They’re including hard certification requirements in their subcontracts

I’ve personally helped primes draft subcontractor flowdowns that say: “Failure to maintain CMMC Level 2 certification may result in termination for convenience.”

And yes, it’s enforceable.

What Should You Be Doing Right Now?

1. Figure Out if You Touch CUI

   • If you’re not sure, assume you do

   • Ask your primes for clarification

2. Do a Real NIST 800-171 Gap Assessment

   • Not just checkboxes—detailed analysis

   • Identify what’s missing and who owns it

3. Build an SSP That Doesn’t Suck

   • No generic templates

   • Tailor to your environment and practices

4. Budget for Audit and Remediation

   • Include internal labor, external consultants, and C3PAO fees

5. Start Tracking Your Evidence

   • Save logs, configs, screenshots, training rosters

   • Organize it by control for fast access

Final Thought: Nobody Gets a Trophy for Almost

This isn’t a “try your best” moment. If you’re serious about defense work, you need to prove it.

CMMC is the price of entry now. Not a nice-to-have. Not a future consideration.

The government is done pretending that PowerPoints count as cybersecurity. They want receipts. And if you don’t have them, someone else will.

So start now. Before the clock hits November 10.

Subscribe now

*Forward to your legal team (or friends) to make sure someone as checked if they need to be compliant!

Subscribe now

7 Potential Diligence Disasters

There comes a time in every startup’s life when someone important (usually a banker, a buyer, or a very expensive lawyer) asks a question that causes immediate, collective panic: “Can you send us your diligence package?”

At that moment, every GC knows whether they’re in a romantic comedy or a horror movie.

Due diligence is the legal version of a home inspection. It’s not just about what’s shiny…it’s about what’s rotting behind the walls. And if you haven’t done your pre-diligence cleanup, the buyer’s team will find:

• The IP is owned by a long-departed co-founder.

• Half the team is misclassified as "consultants" who work full-time and use company laptops.

• The biggest customer has a contract that gives them refund rights and your firstborn.

• The cap table has more versions than Taylor Swift’s last album.

This is your guide to getting ahead of all that. Because when diligence hits, you want to be the GC who hands over a clean binder. Not the one who says, "Let me get back to you on that...maybe in a week."

Disaster #1: The Orphaned IP

What happened: The founders built the MVP before incorporation. Contractors wrote the production code. An intern designed the logo. Nobody signed anything. Everyone just “assumed” the company owned everything because…startup magic?

Why buyers care: Because in the real world, IP doesn’t transfer by osmosis. U.S. law says whoever creates it, owns it, unless they sign a document saying otherwise. If your core product was coded by someone with no signed IP assignment, you don’t own it. You lease it from a ghost.

Real-life facepalm: A startup couldn’t prove it owned its own recommendation engine. A former engineer had written it from his personal GitHub before joining full-time. Diligence paused. The buyer forced a retroactive IP assignment...along with $2M in escrow. Ouch.

What you do now: Make a list of everyone who touched product or content (e.g. founders, contractors, interns, cousin Jimmy) and verify there’s a signed agreement. Use “hereby assigns” language. If they’re gone, hunt them down now, not after LOI.

Also: check for open-source dependencies. A GPL license buried in your backend code is the fastest way to turn a $100M deal into a LinkedIn "life lesson" post.

Disaster #2: The Contractor Class of 2020

What happened: Early stage companies love flexibility. So instead of employees, they hire “contractors.” Contractors who:

• Work full-time.

• Have a company email.

• Get invited to the holiday party.

• Sometimes…manage other employees.

Congratulations. You’ve just built a legal time bomb.

Why buyers care: Because misclassification = liability. Back taxes. Wage claims. Benefit issues. And, here’s the fun twist, potential IP ownership problems, since contractors don’t automatically assign work like employees do.

Real-life facepalm: A company had 30 contractors, all working full-time. One filed for unemployment. The state investigated. The buyer found out. The deal nearly died until the company converted the entire team, re-papered the IP, and added indemnities.

What you do now: Audit classifications. Clean up contracts. Don’t pretend part-time status just because someone’s on a 1099. And if you think calling them “freelancers” fixes it…congrats, you now have a lawsuit and an IRS problem.

Also: make sure HR, Legal, and Finance agree on who’s a contractor. If you ask three people and get three answers, you already know where this is going.

Disaster #3: The Customer Contract from Hell

What happened: You landed a huge customer! They asked for "a few light redlines."

You gave them:

• MFN pricing,

• perpetual exclusivity,

• termination for convenience,

• and a clause allowing them to sue you into oblivion for SLA violations.

Because at the time, you just wanted the logo.

Why buyers care: Because they’re inheriting the contract…and the mess. If one customer controls 40% of revenue and can walk away anytime with a full refund? That’s not recurring revenue. That’s a time bomb.

Real-life facepalm: A healthtech startup agreed to a termination clause where the customer could get a refund for any "unsatisfactory" service. Buyer ran the numbers and called the revenue unreliable. Valuation haircut: $8 million.

What you do now: Review your top 25 customer contracts. Flag:

• Assignment clauses

• Change-of-control triggers

• Refund rights

• Uncapped indemnity

• Data ownership issues

Then fix what you can. And, yes, make future contracts less desperate.

Also: scrub for weird NDAs. You’d be shocked how many companies signed mutual NDAs that say the customer owns anything "related to discussions." Delete that. Fire whoever approved it.

Disaster #4: Export Control Blindness

What happened: You’re a SaaS company. You have users in 60 countries. You use encryption. One developer works in Vietnam. Another in Serbia. Nobody's thought about BIS, OFAC, or EAR. What could go wrong?

Why buyers care: Because export violations = fines. Especially if you’re dealing with encryption software, sanctioned regions, or foreign nationals accessing sensitive backend systems.

Real-life facepalm: A startup had a handful of users from a blocked region. Their signup flow didn’t block embargoed countries. The buyer’s trade counsel caught it. The company had to self-report, purge users, and delay closing.

What you do now:

• Know your ECCN. If you don’t know what that is, ask your friendly neighborhood export lawyer.

• Block embargoed countries in your product and signup flow.

• Screen vendors and contractors for OFAC issues.

• Add export control reps to your terms of service.

Keep in Mind: If you sell anything with end-to-end encryption, buyers will ask for classification documentation. If your team stares blankly, expect a red flag.

Disaster #5: Privacy Policy Fiction

What happened: Your privacy policy was copied from another startup in 2018. Your product tracks everything. No one has mapped what data is collected, stored, shared, or deleted. Meanwhile, you’ve onboarded 42 vendors and none of them signed DPAs.

Why buyers care: Because privacy isn’t just a checkbox anymore. It’s a reputational risk, a legal liability, and a dealbreaker, especially with global users.

Real-life facepalm: A SaaS company had 50 vendors touching user data. Only 9 had DPAs. The company had never responded to a deletion request. Buyer flagged it as non-compliant with GDPR and CCPA. Result: reduced valuation, delayed close, mandatory remediation plan.

What you do now:

• Build a data map. Know what personal data you collect, where it flows, and who has access.

• Get DPAs in place. No excuses.

• Make sure your privacy policy isn’t promising magical rights you don’t provide.

• Keep a breach/incident log. Even for close calls.

Also: check your cookie banner. If it’s a "click to accept" banner with no opt-out, congrats, you now have a CNIL problem.

And don’t forget employee privacy. Diligence isn’t just about user data. Buyers will ask what you track on employees, how you monitor them, and what surveillance software is running. If your answer is, “we installed software that takes screenshots every 30 seconds,” then…good luck.

Disaster #6: The Cap Table That Ate Your Deal

What happened: You thought your cap table was clean. Then:

• A phantom grant surfaces.

• A terminated employee is still vesting.

• The stock ledger doesn’t match Carta.

• The board never actually approved the last option pool increase.

*Check out my full write-up on the Most Common Cap Table Issues

Why buyers care: Because equity is math. And if the math doesn’t work, everything else breaks. Phantom equity, double grants, unapproved options. These are not just administrative headaches. They are lawsuits in waiting.

Real-life facepalm: A startup missed a grant approval for a founding engineer who later left. She exercised anyway. During diligence, the buyer questioned ownership. The startup had to refund the exercise and top her up with a new grant. Morale cratered. So did the price.

What you do now:

• Reconcile your equity records quarterly.

• Verify board approvals. Every. Single. Time.

• Lock down your cap table system. No more dueling spreadsheets.

• Align HR, Finance, Legal, and Payroll or be ready for chaos.

Bonus point: If you’ve got advisors or consultants on equity plans meant only for employees, or early advisors on handshake deals, now’s the time to fix it before someone insists their vesting never stopped.

Disaster #7: Missing Board Approvals & Corporate Records

What happened: The board never approved your new equity plan. The last two SAFE conversions weren’t documented. Your stock certificate book? LOL.

Why buyers care: Because the absence of governance signals one thing: you’re not in control. If you can’t prove the board approved key corporate actions, buyers assume everything is defective until proven otherwise.

What you do now:

• Ensure all board consents and approvals are documented and signed.

• Match stock ledgers to cap table and payroll.

• Confirm all equity plans were adopted properly.

• Upload everything to a central folder. No more digging through inboxes.

And if your Board Secretary is “whoever has free time,” please fix that. Now.

The GC’s Pre-Diligence Toolkit

Want to survive diligence? Here’s your playbook:

• IP Assignments or Bust – Everyone who ever touched product or code must have a signed IP agreement with "hereby assigns" language.

• Contractor Clean-Up – Audit, classify, and convert as needed. If it walks like an employee...

• Contract Landmine Scan – Review and fix customer contracts. Know what you’ve promised.

• Export Control Triage – Determine your ECCN. Screen users. Block embargoed regions.

• Privacy Sanity Check – Map your data. Get DPAs. Align your policy with reality.

• Cap Table Reconciliation – There should be ONE cap table. Make sure it’s clean.

• Governance Hygiene – Match stock ledgers to approvals. Keep consents signed and centralized.

• Run Internal Diligence Now – Do a dry-run. If it would embarrass you to hand it over, fix it before you’re under a microscope.

My 2-cents:

You don’t want to be the lawyer explaining why the company’s IP might belong to a contractor in New Jersey who left three years ago and now sells artisanal jam. You want to be the lawyer who says, “Here’s the diligence binder—IP clean, contracts assignable, no skeletons, and yes, the cap table matches payroll.”

Because the only thing worse than a diligence disaster…is watching your valuation burn because of it.

Buyers aren’t just buying what you built. They’re buying whether you built it right. Whether your house has a solid foundation or just a fresh coat of paint over a leaking basement.

And when that diligence flashlight turns your way, the GC isn’t just a supporting character. You’re the one who proves this company is real, that its value is defensible, and that the wheels won’t fall off the second the ink dries.

So clean the house. Label the boxes. Fix the wiring.

Because no one wants to be the lawyer holding a mop after midnight, whispering, “I thought someone else took care of that.”

Subscribe now