D.C. splits AI and crypto oversight paths

Washington is testing AI with voluntary review while keeping crypto on a compliance leash.

I've been tracking how Washington talks about AI and crypto for a while now, and honestly, the mismatch has been annoying. Same year, same policymakers, same panic about national security, consumer harm, and bad actors. But when I watch the actual policy moves, they don't line up at all. AI gets treated like a strategic race where the government wants a seat at the table without slowing the builders down. Crypto gets treated like a mess that needs reporting, registration, surveillance, and a long paper trail before anyone feels comfortable.

That split matters if you build products, advise companies, or write policy memos for a living. It changes what you ship, what you document, what you tell legal, and how much room you have to move before the regulator shows up. So I dug into Sean Stein Smith's Forbes piece, "AI Vs. Crypto: Why D.C. Is Taking Two Different Paths To Oversight", and pulled out the part that actually matters: D.C. isn't applying one clean theory of oversight. It's using two different playbooks.

AI is being handled like a national-security pilot, not a ban hammer

"Rather than imposing mandatory pre-approval requirements on AI developers, the order establishes a voluntary framework that encourages AI firms to provide models to federal agencies for cybersecurity testing before public release."

What this actually means is simple: the government wants visibility into AI systems before they hit the public, but it doesn't want to turn that into a hard gate that slows every release. That's a very different posture from old-school regulation. It's closer to, "show us what you're building if you want help spotting security problems," not "stop until we sign off."

I ran into this same tension when I helped a team prep an internal model review process. The founders wanted to move fast, but security kept asking for red-team checks, data lineage, and abuse testing. The compromise wasn't a law. It was a process. That seems to be the shape of the federal AI approach here too: nudge, inspect, encourage, but don't freeze the pipeline.

The article says the executive order gives agencies up to 30 days to evaluate systems, with a specific focus on cybersecurity and critical national security risks. That detail matters because it tells me the government is not trying to micromanage model quality or product design. It's looking for the scary stuff first: model theft, misuse, infrastructure risk, and anything that could be tied to state-level competition.

How to apply it: if you're building in AI, start treating government review as a possible pre-launch step, even if it's voluntary. Build a lightweight internal package now. Include model purpose, training data summary, security controls, abuse testing results, and who owns incident response. If the policy environment hardens later, you'll already have the paperwork.

• Make your security review readable by a non-engineer.
• Document the model's intended use and the obvious misuse cases.
• Keep a release log so you can explain what changed and when.

Crypto is still stuck in the compliance-first box

"For much of the last decade, federal oversight of crypto has centered on enforcement, compliance, and jurisdictional disputes."

That line is the whole story. Crypto didn't get a clean policy lane. It got a pile of overlapping agencies and a lot of enforcement energy. The SEC asks whether something is a security. The CFTC looks at commodities. Treasury and FinCEN care about anti-money laundering. Then the tax side shows up and makes everyone miserable in a different way.

What this actually means is that crypto companies spend a ton of time proving they are allowed to exist. Not just "is the product useful?" but "which agency gets to define us?" That is a very different burden from what AI firms are seeing right now. AI is getting a conditional welcome. Crypto is still getting a compliance interview.

I have seen this play out in product planning conversations. A crypto startup can have a clean roadmap and still get trapped by reporting obligations, custody questions, broker definitions, and tax treatment before it even gets to growth. The policy problem isn't just rules. It's uncertainty. If nobody can tell you which bucket you are in, you end up building for legal survival instead of product-market fit.

The Forbes piece points to rules like 1099-DA reporting requirements, expanded broker definitions, AML obligations, and tax compliance expectations. That's not abstract policy language. That's operational drag. It changes your onboarding flow, your transaction logs, your KYC stack, your accounting, and your customer support scripts.

How to apply it: if you're in crypto, don't wait for a single federal framework to rescue you. Build for multi-agency scrutiny now. Keep transaction records clean, separate custody from trading logic where possible, and make your compliance story boring on purpose. Boring is cheaper than a subpoena.

• Map every product feature to the regulator most likely to care.
• Write down your AML, tax, and custody assumptions before launch.
• Assume your logs will be read by lawyers, not just engineers.

Voluntary AI oversight is politics, not just policy

"The Trump administration has emphasized that the objective is to enhance national security while avoiding regulations that could undermine American competitiveness in the global AI race."

What this actually means is that AI policy is being sold as strategy. The government wants the benefits of oversight without looking like it's throttling domestic builders. That is classic Washington compromise, but in this case the framing is doing a lot of work. National security is the acceptable reason to ask questions. Competitiveness is the acceptable reason not to ask too many.

I've been in enough planning meetings to know this pattern. If leadership wants a process but doesn't want to sound anti-growth, they call it "risk management." If they want to sound tough but not restrictive, they call it "testing." Same machine, nicer label. That's what I hear in the executive order described in the Forbes article.

The article also notes earlier proposals reportedly had longer review periods and more oversight, but the final version was trimmed down. That tells me the policy fight wasn't about whether AI needs scrutiny. It was about how visible and how burdensome that scrutiny should be. In other words, the debate was over friction, not principle.

How to apply it: if you're writing an AI policy memo, stop arguing only about whether oversight is good or bad. That argument is lazy. Ask where the friction belongs. Pre-release testing? Post-release audits? Sector-specific review? The real question is where you want the brakes, and how hard you want them to bite.

For builders, this means you should expect more scrutiny around cybersecurity than around model ideology. Don't just prepare a safety story. Prepare a security story. Those are not the same thing, and regulators are clearly paying attention to the one that maps to national defense.

Crypto got fragmented because nobody wanted to own it

"Rather than creating a unified framework from the outset, different agencies have asserted authority over different aspects of the marketplace."

That sentence explains why crypto policy feels like a junk drawer. Nobody got the job of owning the whole category early, so the agencies each grabbed a piece. Securities here, commodities there, AML over there, taxes in the corner. The result is a framework that works like a patchwork quilt, except nobody asked for the quilt and it keeps catching on fire.

What this actually means is that crypto is paying the price for regulatory ambiguity. Once a market grows faster than the legal definitions around it, agencies fill the vacuum with the tools they already have. That is efficient for government. It is miserable for builders.

I remember reviewing a token project where the team kept asking, "Can we just launch and sort this out later?" No. That's the wrong instinct. When the rules are fragmented, later becomes more expensive, not less. Every new jurisdictional claim adds another compliance task, another disclosure, another legal opinion, another delay.

The article is blunt about how market investors and policy advocates saw the system as fragmented and reactive rather than coordinated and pro-innovation. I think that's fair. If your framework starts with enforcement, the market will optimize around fear. That is not a healthy base layer for product development.

How to apply it: stop pretending crypto regulation is one conversation. It is at least four. Build separate workstreams for securities analysis, commodities questions, AML/KYC, and tax. If you try to bundle them, you'll miss something obvious and expensive.

AI gets a sandbox; crypto gets a ledger

"The final version instead reflects a preference for voluntary cooperation between government and private industry."

What this actually means is that AI is being treated like a system the government can study alongside industry, while crypto is being treated like a system the government wants to audit after the fact. One is collaborative experimentation. The other is recordkeeping.

That difference shows up in the kind of product behavior each sector gets rewarded for. AI teams are rewarded for disclosure, testing, and controlled access. Crypto teams are rewarded for traceability, reporting, and proof that money moved the way it was supposed to move. Same broad concern about risk, totally different operating model.

I think this is the part most people miss. Oversight is not just about rules. It's about what kind of company behavior the state is trying to shape. With AI, the state is saying: help us understand the system before it scales. With crypto, the state is saying: tell us exactly what happened after it scaled.

That has real product consequences. AI companies should invest in evals, red-teaming, and security documentation. Crypto companies should invest in audit trails, reporting automation, and legal review that can survive an enforcement inquiry. If you swap those priorities, you will waste time and still be exposed.

How to apply it: decide whether your compliance posture is built for pre-launch review or post-launch audit. If you're in AI, think pre-launch. If you're in crypto, think audit-first. That sounds obvious, but I keep seeing teams blur the two and pay for it later.

The real lesson is that Washington is choosing winners by method

"AI and crypto are moving fast, but being treated very differently."

That's the cleanest summary in the piece, and it's the one I would use in any internal briefing. The government is not simply reacting to speed. It's reacting to the type of risk each technology creates and the political story that risk can support. AI fits a national-security narrative. Crypto fits a financial-integrity narrative. Different stories, different tools.

What this actually means for developers is that you cannot copy one regulatory strategy from one sector to the other and expect it to work. AI teams should not assume crypto-style enforcement is coming first. Crypto teams should not expect AI-style voluntary review to save them. The policy machinery is already split.

I've been around enough product and policy discussions to know the temptation here is to wait for clarity. Bad idea. Clarity usually arrives after the market has already absorbed the cost. The better move is to build as if the current split will last long enough to matter, because it probably will.

So if you're shipping AI, optimize for cooperative review and security evidence. If you're shipping crypto, optimize for records, definitions, and proof. If you're advising leadership, stop asking whether Washington is "pro-innovation." Ask which kind of innovation it is willing to inspect before launch and which kind it wants to police after the fact.

The template you can copy

# D.C. oversight split: AI vs. crypto template

## One-line takeaway
Washington is using voluntary pre-release review for AI and compliance-heavy oversight for crypto.

## What changed
- AI is being treated as a national-security and cybersecurity issue.
- Crypto is still being handled through enforcement, registration, reporting, AML, and tax rules.
- The policy gap is not about speed alone; it is about the kind of risk each technology presents.

## If you build AI
- Maintain a pre-release review packet.
- Include model purpose, training data summary, security controls, and abuse testing.
- Prepare for voluntary agency testing or third-party review.
- Track incidents, model changes, and release dates.

## If you build crypto
- Map every product flow to securities, commodities, AML/KYC, and tax questions.
- Keep transaction logs and custody records clean.
- Document broker, reporting, and disclosure assumptions.
- Assume post-launch audits and enforcement scrutiny.

## If you write policy or strategy
- Do not use one oversight model for both sectors.
- For AI, focus on cybersecurity and pre-launch testing.
- For crypto, focus on compliance, definitions, and auditability.
- Separate the regulatory workstreams instead of bundling them.

## Internal memo version
Washington is treating AI and crypto differently on purpose. AI is getting voluntary pre-release scrutiny tied to cybersecurity and national security, while crypto remains in a fragmented compliance regime built around enforcement, reporting, AML, and tax obligations. Companies should prepare for different operating assumptions in each sector.

## Copy-ready checklist
- [ ] AI release packet prepared
- [ ] Security testing documented
- [ ] Abuse cases listed
- [ ] Crypto transaction logs retained
- [ ] AML/KYC workflow reviewed
- [ ] Tax and reporting assumptions documented
- [ ] Legal owner assigned for each regulatory bucket

Sean Stein Smith's Forbes article is the source I used for the policy details and framing, and I kept the analysis here intentionally practical rather than trying to restate the whole piece. The original piece is at forbes.com/sites/digital-assets/2026/06/05/ai-vs-crypto-why-dc-is-taking-two-different-paths-to-oversight/; the template above is my distilled, derivative take for builders and operators.