what applies now#

Manufacturers of products with digital elements sold in the EU must report, to ENISA and the relevant national CSIRT:

Actively exploited vulnerabilities in their product:

• Early warning within 24 hours of becoming aware.
• Vulnerability notification within 72 hours, with corrective measures taken or planned.
• Final report within 14 days of a corrective measure being available.

Severe incidents affecting the security of the product:

• Early warning within 24 hours.
• Incident notification within 72 hours.
• Final report within one month.

The trigger is actively exploited, not merely discovered. A vulnerability you found yourself and are patching quietly is not in scope. One being used against your users is.

the part that is an engineering problem#

24 hours is short, and the clock starts when you become aware. That makes two things load-bearing that most organisations have never tested.

Can you tell that something is being exploited? Reporting an actively exploited vulnerability requires knowing it is being exploited, which requires detection you either have or do not. Exploitation of a deployed product is frequently discovered by a customer, a researcher, or a vendor — and the path from "a customer mentioned something odd" to "our security team knows" is where the 24 hours goes.

Who is authorised to file? At 2 a.m. on a Sunday, with an active exploit, somebody has to decide that the threshold is met and submit a report to a regulator. If that requires a lawyer who is asleep and a VP who is on a plane, you will miss the window.

Both of those need to be settled in advance, written down, and rehearsed. They are not legal problems; they are incident-response problems with a legal deadline attached.

what to do this week#

1. Determine whether you are a manufacturer under the Act. If you place a product with digital elements on the EU market, you probably are. If you provide a service, the rules differ. This is a legal determination and it should already have been made — if it has not, that is the first task.

2. Write the decision tree. What counts as awareness. Who assesses. Who authorises. What the fallback is when they are unavailable. One page.

3. Pre-register and pre-fill. Know which portal, which national CSIRT, and have the product identifiers, version ranges and contact details ready. Do not be looking those up during the 24 hours.

4. Wire your intake. Every path by which you could learn of exploitation — support, your security contact address, your bug bounty, your CSIRT relationships — needs a route to the person who assesses. Test it by sending something through and timing it.

5. Run the drill. A tabletop exercise with a fictional exploited vulnerability. Time how long it takes to reach a filing decision. That number is your actual capability, and it is usually much worse than people expect the first time.

the open source position, again#

Worth restating because it keeps being misunderstood: an individual maintaining open source outside a commercial activity is not a manufacturer and has no reporting obligation. The duty sits with whoever puts the product on the market.

What will happen anyway is that companies with the obligation start asking their dependencies for security contacts and disclosure policies. Those requests are not legally owed. Publishing a SECURITY.md is a kindness, not a compliance requirement, and no maintainer should be pressured into treating it as one.

If you are the company with the obligation: build the reporting capability yourself, from information that is already public, and fund the projects you depend on. That is the response that actually works.

what applies now#

For providers of high-risk systems — those used in employment, education access, credit, essential services, law enforcement, migration, justice, and as safety components in regulated products:

• Risk management system, documented and maintained across the lifecycle.
• Data governance, with documented training, validation, and test data and attention to bias.
• Technical documentation sufficient for conformity assessment.
• Automatic logging of the system's operation, retained.
• Transparency to deployers about capabilities, limitations, and intended use.
• Human oversight designed into the system.
• Accuracy, robustness, and cybersecurity proportionate to the purpose.
• Conformity assessment and CE marking before placing on the market.
• Registration in the EU database.
• Post-market monitoring and serious incident reporting.

Deployers — organizations using a high-risk system rather than supplying it — have a lighter but real set: use it according to instructions, ensure input data is relevant, monitor operation, retain logs, and assign competent human oversight.

the parts that moved#

The implementation timeline has been adjusted more than once during the run-up, which is normal for regulation of this scope and which made planning genuinely difficult for anyone trying to comply.

The important practical consequences:

Some obligations phase in later for systems already on the market, and for high-risk systems that are safety components of products covered by other EU legislation.

Harmonised standards are still being finalised. Conformity assessment is easier when you can demonstrate compliance against a standard; where standards are not yet available, providers must demonstrate compliance against the requirements directly, which is more work and more uncertain.

Enforcement capacity varies by member state. Market surveillance authorities are at different stages of readiness. That is not a reason to assume non-enforcement — it is a reason to expect inconsistency in the first period.

Check the current state before making decisions. The details have moved and may move again.

what to do if you are in scope#

If you have not classified your systems, do that today. It is the prerequisite for everything else and it is a legal question with technical inputs. A number of organizations discover they are in scope for one feature they had not considered — a CV screening tool, a proctoring feature, a creditworthiness proxy.

Documentation is the bulk of the work. Training data provenance, validation methodology, known failure modes, intended use and misuse. Most engineering teams do not have this written down and reconstructing it is slower than producing it as you go.

Logging is a technical requirement. Automatic recording of operation, retained, with enough detail to trace a decision. If your system does not do this, it is engineering work with a deadline that has passed.

Human oversight is a design constraint, not a checkbox. "A person reviews the output" is insufficient if the person cannot meaningfully understand, question, or override it. Surfacing confidence, explaining the inputs that drove a decision, and making override easy and recorded are interface requirements.

if you are not in scope#

Most software is not. The transparency obligations — disclose that users are interacting with an AI system, label synthetic media — apply much more broadly and are much lighter.

The thing worth doing regardless of scope: know which category you are in, and write down why. "We assessed this and concluded it is not high-risk because X" is a one-page document that saves an enormous amount of time when someone asks, and someone will ask.

the honest assessment#

The Act is the most comprehensive AI regulation any jurisdiction has attempted. It has real criticisms — compliance cost falls hardest on small companies, the risk categories map imperfectly onto how systems are actually built, and the standards process has lagged the deadlines.

It is also law, it has extraterritorial reach, and penalties scale with global turnover.

The organizations that started classification work a year ago are in reasonable shape today. The ones that waited for clarity are discovering that regulatory clarity tends to arrive after the deadline rather than before it, which is a lesson that generalizes well beyond this particular Act.

Enough time has passed to say what actually happened rather than what everyone predicted.

what changed#

The norm inverted. Before, crawling was permitted by default and robots.txt was a request. Now, for a large share of the web, crawling is denied by default and access is a negotiation.

That is a genuine structural change to how the web works and it happened through one company's configuration default rather than through any standards process, legislation, or public deliberation.

Licensing deals concentrated. Large AI companies negotiated bulk access with large publishers. That was always the likely outcome: the parties with lawyers and leverage made arrangements, and the arrangements are private.

Small publishers got very little. The pay-per-crawl mechanism works, technically. The revenue for a site with modest traffic is negligible — the arithmetic never supported anything else. The publishers who most needed a new economic model got the one that pays least.

Non-commercial crawling got harder. Academic researchers, archivists, and independent search projects have no licensing budget and no negotiating position. Carve-outs exist and are discretionary, which means the ability to study the web is now something you apply for.

That is the outcome I was most worried about and it is the one that materialized most clearly.

what did not change#

Training data supply. The frontier labs have enormous existing corpora, licensed sources, and synthetic generation. The marginal value of newly crawled web text was already declining. Restricting it did not create the leverage publishers hoped for.

Traffic. Referral traffic from search to publishers continued its decline, driven by AI answers in search results, which is a completely separate mechanism from training crawlers and which blocking crawlers does nothing about.

This is the part that was most misunderstood at the time. The traffic problem and the training problem have different causes and blocking crawlers only addresses one of them — the one with less economic impact.

the thing to actually take from it#

Infrastructure defaults are policy. A configuration change at a chokepoint reshaped access to a large fraction of the web, with no process and no appeal.

That is not a criticism of the specific decision, which was popular and defensible. It is an observation about where power actually sits, and it generalizes: the entities that can change the web's behavior are the ones with concentration at a layer everyone depends on, and there are about five of them.

For your own site, the decision remains yours and it is worth making deliberately rather than accepting a default:

• Documentation sites frequently want to be in the training data. Being the thing the model knows about is worth more than the pageview you did not get.
• Original reporting and analysis has a stronger case for restriction.
• Anything you want found should still permit search crawlers, which are a different category and are frequently blocked by accident when people configure this.

Check what you are actually blocking. A meaningful number of sites blocked their own search indexing in the first months of this and did not notice for weeks.

the unresolved thing#

The web's economic model — publish freely, get traffic, monetize traffic — is breaking, and nothing has replaced it.

Crawler tolls are not the replacement; the arithmetic does not work at the scale of the actual web, where most content is made by people with no ability to negotiate anything.

Licensing deals are not the replacement either; they work for a few hundred large publishers and for nobody else.

I do not know what the replacement is. I am increasingly convinced that nobody does, and that the interval between the old model failing and a new one existing is going to be long and is going to be bad for the open web.

That is a genuinely pessimistic conclusion and I have not found a way around it in a year of thinking about it.

This is not legal advice. It is the working map.

the permissive family#

MIT, BSD (2- and 3-clause), ISC, Apache 2.0.

What you must do: include the license text and the copyright notice with your distribution. That is essentially it.

What you may do: everything. Use it commercially, modify it, ship it in a closed product, sublicense it.

Apache 2.0 additionally: grants patent rights explicitly, and terminates those rights if you sue a contributor for patent infringement over the software. It also requires you to state significant changes you made.

That patent grant is why Apache 2.0 is preferred over MIT by legal departments at larger companies. MIT is silent on patents, which is not the same as safe.

In practice: include a NOTICES file or an attribution page listing your dependencies and their license texts. Generate it from your dependency tree. This is the entire compliance obligation for the permissive family and most products do not do it.

the weak copyleft family#

LGPL, MPL 2.0, EPL.

The rule: modifications to the licensed files must be released under the same license. Your own code that merely uses the library does not have to be.

MPL 2.0 is file-based, which is the cleanest formulation: if you modify a file that came under MPL, that file stays MPL. Everything else is yours.

LGPL is linking-based and the details matter. Dynamic linking is generally considered fine — the user must be able to replace the library. Static linking requires either providing object files so the user can relink, or releasing under compatible terms.

For most modern language ecosystems, "dynamic linking" does not map cleanly onto how code is actually distributed, and this is a genuine gray area. If you statically link LGPL code into a distributed binary, that is worth a real legal conversation.

In practice: MPL and EPL are unproblematic for most commercial use. LGPL is usually fine and deserves attention if you are shipping a compiled binary rather than running a service.

the strong copyleft family#

GPL v2, GPL v3.

The rule: if you distribute a work based on GPL code, the whole work must be under the GPL, and you must provide source.

The key question is what "distribute" means. Running GPL software on your server and letting users access it over a network is not distribution. This is why a very large amount of GPL software runs inside commercial SaaS products without obligation — Linux being the obvious example.

GPL v3 additionally: anti-tivoization (you must let users install modified versions on hardware you ship), and explicit patent provisions.

In practice: GPL dependencies in a hosted service are usually fine. GPL dependencies in software you ship to customers make your software GPL, which is usually not what you intended.

Know which of your dependencies are GPL. Most people do not.

the network copyleft family#

AGPL v3.

The rule: GPL, plus — if users interact with the software over a network, they must be able to get the source, including your modifications.

This closes the "SaaS loophole" deliberately. It is why many companies have a blanket policy prohibiting AGPL dependencies: the obligation is triggered by normal SaaS operation, and determining exactly how much of your system counts as "the software" is a question nobody wants to litigate.

In practice: if your company has a license policy, AGPL is almost certainly on the prohibited list. Check before you add the dependency, not after.

the source-available family#

BUSL, SSPL, Elastic License, various "fair source" licenses.

These are not open source licenses. They restrict commercial use, usually prohibiting offering the software as a service that competes with the licensor.

They exist because hyperscalers built managed services on open source projects without contributing back, and the projects had no recourse. That grievance is real.

In practice: read the actual text, every time. They differ substantially. Many convert to an open source license after a delay — BUSL typically becomes Apache 2.0 after four years — which means the version you are using today may become permissive before you care.

The specific question to answer: does your use case compete with the licensor's commercial offering? Usually the answer is obviously no and you are fine.

the practical program#

1. Generate an SBOM in CI. Every build, listing every dependency and its license. Tooling for this is mature in every major ecosystem.

2. Fail the build on prohibited licenses. Have a policy — usually: permissive fine, weak copyleft fine, GPL depends on whether you distribute, AGPL and source-available require review.

3. Generate the attribution file automatically. This is the actual compliance obligation for the licenses you are most likely to use, and generating it is a build step, not a project.

4. Check when you add, not when you ship. The cost of removing a dependency after it is embedded is enormous. The cost of checking at npm add time is zero.

the thing that trips people up#

License compatibility is not transitive intuition. You can use GPL code in a GPL project. You cannot use GPL code in an Apache-licensed library that others will embed in proprietary software — you have made your library effectively GPL, and your users will find out later.

If you publish a library, its license must be compatible with every dependency it pulls in. Check that specifically, because it is the mistake that is expensive to discover after adoption.

Five models. Each works. Each works for a specific kind of project.

1. donations and sponsorship#

Works for: developer-facing tools with a large individual user base and an identifiable maintainer.

Does not work for: libraries deep in a dependency tree, infrastructure nobody knows they use, anything without a personality attached.

The honest arithmetic: donation income correlates with visibility, not with importance. A well-marketed CLI tool with a charismatic maintainer will out-earn a critical cryptography library by a large multiple.

The corporate sponsorship version works better than individual donations and requires the maintainer to do sales, which most maintainers are bad at and hate.

2. foundation governance#

Works for: infrastructure that multiple large companies depend on and that none of them wants a competitor to control.

Does not work for: small projects. The overhead — governance, legal, trademark, process — is substantial, and a foundation with one project and no funded staff is just more paperwork.

The real value of a foundation is not money. It is neutrality: it makes a project safe for competitors to invest in together, which unlocks contribution that would not otherwise happen.

3. dual licensing#

Works for: libraries embedded in other products, where the copyleft obligation is genuinely inconvenient for commercial users.

Ship under a strong copyleft license, sell a commercial license to companies that cannot comply.

Does not work for: anything permissively licensed already (no leverage), anything not embedded (the obligation does not bite), or anything with a permissive competitor of similar quality.

Effective when it fits, and it produces a genuine tension: the license that makes the business work is the one that limits adoption.

4. open core#

Works for: products where enterprise features are genuinely separable from the core — SSO, audit logs, RBAC, compliance reporting, multi-tenancy.

Does not work for: libraries. There is no enterprise tier of a date-parsing library.

The failure mode is well documented: the line between core and commercial moves toward commercial over time, under revenue pressure, and the community that built your adoption watches features they use get moved behind the paywall.

If you do this, write down the line publicly, early, and honor it. "Anything that a single developer needs is open; anything that exists because you have a compliance department is commercial" is a defensible line. Moving it later costs more trust than the revenue is worth.

5. hosted service#

Works for: anything that is annoying to operate. Databases, search, queues, observability, CI.

Give away the software, sell the operation of it. This is the strongest model when it fits, because the value you sell — not having to run it — is real and continuous, and it does not require withholding anything.

The risk: a hyperscaler offers a managed version of your software, at scale, without contributing back. This has happened repeatedly and it is why the source- available licenses exist.

Those licenses solve the problem and cost you the open source designation, which costs you contributors, ecosystem inclusion, and some corporate adoption. It is a real trade with real costs on both sides, and the projects that made it mostly survived, which is the empirical answer to whether it works.

what actually kills projects#

Not the absence of a model. Three other things:

Solo maintainer burnout. One person, unpaid, receiving an unbounded stream of issues, feature requests, and entitled demands. Funding helps and does not fix it — the fix is more maintainers, which is a governance problem.

Success without support. A project that becomes critical infrastructure while its maintainer count stays at one. This is the most dangerous state and it is extremely common.

Corporate abandonment. A company open-sources a project, staffs it with employees, then reorganizes. The external community was never built because it was never needed. Now nobody knows the code.

what companies should do#

If your business depends on open source — and it does — the highest-leverage actions, in order:

1. Pay maintainers of your critical dependencies. Directly. Small amounts to many projects beat large amounts to a few.
2. Assign employee time to upstream contribution. More valuable than money and much rarer.
3. Do not send compliance questionnaires to volunteers. They owe you nothing and the license says so.
4. When you fix a bug in a vendored dependency, upstream it. The number of companies carrying private patches for bugs everyone has is enormous.

None of that requires a strategy document. It requires someone with budget deciding it matters, which is the actual bottleneck.

If you sell software into Europe, this is a real compliance project. If you maintain open source, the situation is more nuanced than either the panic or the reassurance suggests.

what it requires#

For products with digital elements — which is essentially any software or connected device sold commercially:

• Security by design and by default. Documented, with a risk assessment.
• No known exploitable vulnerabilities at time of release.
• Security updates for a support period, minimum five years or the expected product lifetime.
• A software bill of materials, maintained.
• Vulnerability disclosure process, published.
• Reporting of actively exploited vulnerabilities to the authorities within 24 hours of becoming aware, with follow-ups.
• CE marking and conformity assessment, the depth of which scales with product criticality.

That last set of obligations is the near-term one and the 24-hour clock is aggressive.

the open source position#

The Act was substantially amended after the initial draft caused an outcry from the open source community. The current position, roughly:

Not covered: software developed and supplied outside the course of a commercial activity. A maintainer publishing a library for free is not a manufacturer.

Covered: anyone who integrates that library into a commercial product. The obligation lands on the person selling the product, not on the upstream.

Partially covered: a new category of "open source software steward" — foundations and organizations that support the development of open source used in commercial products. Stewards have lighter-touch obligations around security policy and cooperation with authorities, not full manufacturer duties.

That structure is basically correct. The obligation should sit with the entity taking money for the product.

the part that will still hurt#

The obligation may not flow upstream legally, and it will flow upstream socially.

A company that must produce an SBOM, attest to no known exploitable vulnerabilities, and report incidents within 24 hours will start asking questions of its dependencies. Those questions arrive as GitHub issues addressed to unpaid maintainers:

• "Can you provide an SBOM for this library?"
• "What is your vulnerability disclosure policy?"
• "Can you commit to a support period?"
• "Please fill out this 40-question security questionnaire."

None of that is legally required of the maintainer. All of it will land in their inbox, and the maintainer of a two-thousand-line utility with a hundred million downloads is going to receive a lot of it.

The predictable outcome: some maintainers will comply out of conscientiousness and burn out. Some will add a line to their README saying they provide no warranties and will not respond to compliance requests, which is entirely their right. Some will archive the project.

what companies should actually do#

If you are the one with the obligation:

Do not send questionnaires upstream. Answer the questions yourself, about your product, using the information that is publicly available. That is what the regulation asks of you.

Generate the SBOM from your build, not by asking your dependencies. Tooling for this is mature.

Fund the projects you depend on. This is the actually effective response, it is cheap relative to compliance costs, and it is the only thing that improves the underlying situation. A maintainer with funding can respond to security reports; one without cannot.

Have a vendored fallback plan for critical dependencies with a single maintainer. If they archive the project, what do you do? Answer that before you need to.

the honest assessment#

The Act is trying to fix a real problem: consumer devices ship with known vulnerabilities and are never patched, and there has been no consequence for that. The obligations on manufacturers are reasonable and overdue.

The risk is that compliance cost lands disproportionately on small companies and that pressure lands informally on volunteers who owe nobody anything.

The mitigation for both is the same and it is boring: fund maintenance, generate your own compliance artifacts, and do not treat your dependencies' authors as your vendors. They are not, they never agreed to be, and the license says so explicitly.

the structure, briefly#

The Act is risk-tiered rather than technology-specific.

Prohibited (in force since February 2025). Social scoring, certain biometric categorization, emotion recognition in workplaces and schools, untargeted facial image scraping, and manipulative techniques exploiting vulnerabilities.

High-risk (August 2026 for most). Systems used in employment decisions, education access, credit scoring, essential services, law enforcement, migration, justice administration, and as safety components in regulated products.

Limited risk. Transparency obligations. Tell people they are talking to an AI. Label synthetic media.

Minimal risk. Most software. No specific obligations.

General-purpose AI models. Separate obligations that began August 2025 — documentation, copyright policy, training data summaries, and additional requirements for models above a compute threshold.

the classification question#

Most of the compliance work is answering "is my system high-risk," and the answer is less obvious than people assume.

The high-risk categories are defined by use, not by technology. A simple scoring model used to filter job applicants is high-risk. A sophisticated transformer used to suggest recipes is not.

Specific things that catch people:

• Recruitment tooling. Anything that screens, ranks, or filters candidates. This includes a keyword filter, not just an ML model.
• Employee evaluation. Performance assessment, task allocation, monitoring that affects work relationships.
• Creditworthiness. Including proxies for it.
• Educational assessment. Grading, admission, proctoring.
• Safety components in products already covered by EU product safety legislation — which is a long list including machinery, medical devices, and vehicles.

If any of those describe your product, you have obligations, and if you are a provider (you put it on the market) rather than a deployer (you use it), the obligations are substantial.

what high-risk actually requires#

• A risk management system, documented and maintained across the lifecycle.
• Data governance — documented training, validation, and test data, with attention to bias and representativeness.
• Technical documentation sufficient for a regulator to assess conformity.
• Automatic logging of the system's operation.
• Transparency to deployers about capabilities and limitations.
• Human oversight designed in — a person must be able to understand, intervene, and override.
• Accuracy, robustness, and cybersecurity appropriate to the purpose.
• Conformity assessment before market placement, and CE marking.
• Registration in an EU database.
• Post-market monitoring and serious incident reporting.

That is a quality management system, not a checklist. The nearest analogue is medical device regulation, and it is deliberately modeled on it.

the practical advice#

Classify now. Before anything else, determine which of your systems fall in scope. This is a legal question with technical inputs and it should involve both. A lot of organizations discover they are in scope for one feature they did not think about.

Documentation is the bulk of the work. Most engineering teams do not document their training data provenance, their validation methodology, or their known failure modes. The Act requires all of it. Starting that documentation now is cheaper than reconstructing it later.

Logging is a technical requirement with a deadline. Automatic recording of system operation, retained, with enough detail to trace a decision. If your system does not do this, that is engineering work, and it is not trivial to add.

Human oversight is a design constraint. "A person reviews the output" is not sufficient if the person cannot meaningfully understand or override it. Designing for genuine oversight — surfacing confidence, explaining inputs, making override easy and recorded — affects your interface.

Watch for timeline adjustments. There has been active discussion about simplification and phasing, and the details have moved before. Track it, and do not use possible delay as a reason to defer classification, which is the part with the longest lead time.

the honest framing#

Whatever you think of the Act's design — and there are serious criticisms about compliance cost for small companies and about whether risk categories map cleanly onto real systems — it is law, it has extraterritorial reach, and the penalties are proportional to global turnover.

For most developers building most software, none of this applies. For the ones it applies to, six months is not very long.

the mechanism#

A datacenter campus needs a lot of power at one point on the grid. Delivering it requires transmission upgrades, substation construction, and often new generation. Those cost billions and take years.

Who pays is decided by state public utility commissions in rate cases. The options:

• The datacenter pays, through special contracts with minimum-take provisions and upfront infrastructure contributions.
• All ratepayers pay, spread across the customer base, which is how transmission has traditionally been socialized.
• Some blend, which is what actually happens.

Utilities generally prefer the blend, because socialized costs are easier to recover and because they earn a regulated return on capital investment — which means building more infrastructure is directly profitable for them regardless of who uses it.

Consumer advocates object. Datacenter operators object to bearing the full cost. Commissions split the difference, differently in every state.

why this is now the binding constraint#

Chips are available. Capital is available. What is not available is a grid interconnection on a useful timeline.

Interconnection queues in most US markets run years. Transformer lead times remain long. Transmission line construction requires siting approval, which requires public process, which is where projects die.

So the sequence for new capacity is: secure a site with grid access, sign a power agreement, wait. The waiting is the schedule. Everything else can be compressed with money; this cannot.

what it means for compute prices#

Two effects pulling in opposite directions.

Regional differentiation increases. Regions with available power and cooperative regulators get capacity. Regions without do not. That produces real price differences between cloud regions for the same instance type, larger than the historical spread.

Off-peak becomes genuinely cheaper. Grid economics are about peak demand. Workloads that can shift to off-peak hours are worth real money to operators, and that value will get passed through as pricing. Batch inference, training runs, and anything asynchronous is a candidate.

what to actually do#

Check regional pricing before you pick a region by habit. The default region in your organization was chosen years ago for reasons that may no longer hold. For a large workload the difference is material.

Make batch work time-flexible. If your nightly job can run in a four-hour window instead of at a fixed time, you can take spot capacity and off-peak pricing. This is a small engineering change with a large cost effect and almost nobody does it.

Measure your actual utilization. The cheapest watt is the one you do not use. A very large fraction of provisioned cloud compute runs at low utilization, and in an environment where power is the constraint, that waste is now expensive rather than merely inelegant.

Watch your provider's regional capacity announcements if you are planning anything large. Capacity comes online in steps tied to substation energization dates, and knowing the schedule is worth something.

the part that is not about your bill#

There is a legitimate public policy question here that the industry mostly does not want to engage with: whether the cost of connecting datacenters should be borne by households whose electricity bills are rising.

The industry's answer is usually that datacenters bring jobs and tax revenue, which is true and is a smaller number than the capital involved. The honest version is that the buildout is happening faster than the institutions that allocate its costs can deliberate, and the allocations being made now will be argued about for a decade.

Engineers do not decide this. Engineers do decide how much power their systems consume, and that has stopped being an abstract concern.

harvest now, decrypt later#

The threat model that makes this urgent has nothing to do with when a cryptographically relevant quantum computer arrives.

An adversary records your encrypted traffic today and stores it. When they can break the key exchange — in five years, in fifteen — they decrypt the archive.

So the question is not "when will quantum computers work." It is: how long does your data need to stay confidential?

• Session tokens: minutes. Do not care.
• Customer PII: years to decades. Care a lot.
• Medical records: a lifetime. Care enormously.
• Government and defense: generational.
• Source code and trade secrets: depends, usually longer than you think.

If anything you transmit has a confidentiality horizon past roughly 2035, traffic you send today is already at risk. That is the whole argument and it does not depend on any prediction about quantum hardware.

what is standardized#

NIST finalized the core standards:

• ML-KEM (FIPS 203), formerly Kyber — key encapsulation. This is the one that matters for TLS.
• ML-DSA (FIPS 204), formerly Dilithium — digital signatures.
• SLH-DSA (FIPS 205), formerly SPHINCS+ — hash-based signatures, conservative fallback with larger signatures.

The guidance across national security agencies is consistent: begin migration now, complete it well before 2035, prioritize by confidentiality horizon.

what is already shipping#

More than most people realize.

TLS key exchange. Hybrid X25519 plus ML-KEM is deployed by default in major browsers and supported by major CDNs and load balancers. A meaningful fraction of web traffic is already post-quantum protected for key exchange, and most people running those services did not do anything to enable it.

Check yours:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 \
  | grep -i "negotiated\|group"

SSH. OpenSSH has shipped post-quantum key exchange by default for several releases. If your servers are current, your SSH sessions are already hybrid.

Signatures are lagging, and that is the harder half. Certificate chains, code signing, and firmware verification all involve long-lived trust anchors and ecosystem-wide coordination. ML-DSA signatures and public keys are substantially larger than ECDSA, which has real consequences for handshake size, embedded devices, and anything with a fixed-size signature field.

what to actually do this year#

1. Inventory your cryptography. Where do you use asymmetric crypto, with what algorithm, and what is the confidentiality or integrity horizon? Most organizations cannot answer this and the exercise is more valuable than any individual migration step.

2. Get to hybrid key exchange. For most people this means: update TLS libraries, update the load balancer, verify the negotiated group. It is largely free and it addresses the harvest-now threat, which is the urgent one.

3. Build crypto-agility. The lasting fix is not "migrate to ML-KEM." It is "be able to change algorithms without a rewrite." Hard-coded algorithm choices scattered through a codebase are the actual problem, and they will be the problem again for whatever comes after this.

Centralize crypto in one module. Make the algorithm a configuration value. Version your protocol so you can negotiate.

4. Ask your vendors. Every SaaS provider, every library, every hardware security module. The answers will be uneven and asking creates the pressure that fixes it.

5. Do not roll your own. Use the vetted implementations. The failure mode for post-quantum crypto is a side-channel in a hand-written implementation of a lattice operation, and that failure is silent.

the thing that makes this hard#

It is a migration with no visible benefit. Nothing gets faster. No feature ships. The success condition is that in fifteen years, nothing bad happens.

That is the hardest kind of project to fund, and it is why the organizations that do it well will be the ones that started when it was still early enough to be cheap.

the model#

Genuinely better than the first version, in ways that matter:

• Synchronized audio. Dialogue, effects, ambience generated with the video.
• Physical plausibility. Objects have more consistent mass and momentum. Things that fall, fall correctly. Water behaves like water.
• Failure realism. A demonstrated example: a basketball shot that misses bounces off the rim, rather than teleporting into the hoop because the model learned that shots go in. Modeling failure states is a meaningful step toward actual physics rather than outcome mimicry.
• Multi-shot consistency. The same character and setting across cuts.

the app#

A TikTok-shaped feed where every video is generated. OpenAI's stated framing is creation over consumption, with feed controls and usage prompts.

I am skeptical, and the skepticism is structural rather than about intent. An infinite feed of content optimized for engagement has one known equilibrium, and it does not depend on whether the content is human-made. If anything, generated content removes the last friction — there is no supply constraint at all.

The genuinely novel bit is cameos: a verified likeness capture, with control over who can use it, revocable, with notification when it appears in someone's video.

That consent architecture is thoughtful. It is also the thing that will be stress-tested immediately, because likeness in generated video is the single most socially dangerous capability in this space and "we built a consent flow" is a much better answer than most products have.

Revocation is the hard part. You can revoke permission going forward. You cannot revoke a video someone downloaded.

the rights problem#

Reporting around the launch indicated a rightsholder posture that put the burden on IP owners to opt out rather than requiring opt-in, with an announced shift toward more granular controls after pushback.

Opt-out for likeness and IP is a defensible engineering default and an indefensible ethical one. It puts the cost of protection on the person being depicted, who may not know the product exists.

I expect this to be litigated and legislated, in that order, and I expect opt-in to win for likeness specifically because that is where the political consensus already is.

for developers#

The API is available and the practical questions are the same as for image generation, more sharply:

• Provenance metadata on everything. C2PA, watermarking, whatever your pipeline supports. This is going to be a requirement, not a nicety.
• Consent flows for likeness, designed in from the start. Retrofitting consent after you have a user base is a nightmare.
• Understand your jurisdiction's rules on synthetic media. They are being written right now and they differ substantially between the EU, several US states, and everywhere else.

the broader read#

We are about eighteen months from generated video being indistinguishable from recorded video for a casual viewer, and the social infrastructure for that — norms about disclosure, verification for journalism, legal standards for evidence — does not exist.

The technology is arriving considerably faster than the institutions. That is not a new observation, and it has rarely been this compressed.

Cloudflare sits in front of roughly a fifth of the web. A default change at that position is not a product launch, it is a policy change for the internet.

the mechanism#

Two pieces.

Default blocking. New zones get AI crawler blocking on unless the operator opts out. Cloudflare maintains the bot classification — separating search crawlers, which drive traffic back, from training crawlers, which do not.

Pay-per-crawl. A site sets a price. A crawler that wants the content gets an HTTP 402 Payment Required with terms. Cloudflare handles settlement.

HTTP 402 has been "reserved for future use" since 1997. It is genuinely funny that this is what activated it.

why the old system failed#

robots.txt is a request, not a control. It works because well-behaved crawlers choose to honor it, and that consensus held for thirty years because search engines had an incentive to be well-behaved — they needed publishers to not block them.

AI training crawlers have no such incentive. The content is valuable to them and the traffic they return is zero or nearly so. Multiple studies found training crawlers ignoring robots.txt, rotating user agents, and using residential proxy pools. Once a norm has no enforcement and no incentive, it stops being a norm.

Cloudflare's move replaces a request with a control. That is the actual innovation and it required no new technology at all — just someone at a chokepoint deciding to enforce.

the case against#

Concentrating the ability to gate the web at one CDN is not obviously good, even if this specific use of the power is popular.

The precedent is: an infrastructure company can unilaterally change how content is accessed for a large fraction of the internet, and the mechanism generalizes to things other than AI crawlers. Cloudflare has been thoughtful and has taken public positions on not being an arbiter, and the concentration is still real.

There is also a smaller-player problem. Large AI companies can negotiate licensing deals directly. Researchers, startups, the Internet Archive, and academic crawlers cannot. A tollbooth is regressive: it is a rounding error for the incumbents and a barrier for everyone else. Cloudflare has carve-outs for some of these and the carve-outs are discretionary, which is the point.

for developers#

Two practical items.

If you run a site, decide deliberately. Blocking training crawlers is now the default; that may not be what you want. Documentation sites in particular may prefer to be in the training data, because being the thing the model knows about is worth more than the pageview you lost.

If you build anything that crawls, expect 402s and expect your user agent to matter. Identify honestly, respect the directives, and set up billing if you need paid access. The era of scraping quietly is ending, and the enforcement is technical now rather than legal.

the bigger shift#

The web's economic model was: publish freely, get traffic, monetize traffic. AI answers break the second step, which breaks the third, which will eventually break the first.

Pay-per-crawl is one proposed replacement. Licensing deals are another. Neither is obviously going to work at the scale of the actual web, where most content is made by people with no ability to negotiate anything.

What replaces it is genuinely unresolved, and 2025 is the year everybody stopped pretending otherwise.

The technical achievement is real and got buried under the meme, which is a shame, because the technical achievement is the interesting part.

what is actually different#

Previous image generation from a chat interface was a handoff: the model wrote a prompt, a separate diffusion model rendered it, and the chat model never saw the result in any meaningful sense. You could not say "same picture but move the cat" because there was no shared representation.

Native generation means the same model produces the image tokens. That gives you:

• Real editing. "Make the sign say something else" works, because the model understands the scene it produced.
• Text that renders correctly. This has been the single most obvious tell of AI images for three years, and it is largely fixed. Infographics, diagrams, menus, and UI mockups now come out legible.
• Instruction following at a level diffusion models never had. Ten objects with specified positions and colors. Diffusion models fall apart around four.

For developers specifically, the practical unlock is diagrams and mockups. "Draw me an architecture diagram with these six services and these arrows, in a clean technical style" now produces something you can actually put in a document.

the part everyone is arguing about#

Studio Ghibli did not consent to this and Hayao Miyazaki has been publicly, memorably contemptuous of AI-generated animation for years.

The legal position is genuinely unsettled. Copyright does not protect style — you cannot own "watercolor backgrounds and round faces" — which is why the outputs are probably not infringing on their face. Whether training on the works to acquire the style is infringement is the actual contested question, and it is being litigated in several jurisdictions simultaneously with no consistent answer yet.

The ethical position is less unsettled and more uncomfortable. A studio spent four decades developing a visual language through enormous manual labor — Miyazaki's teams famously hand-drew crowd scenes frame by frame — and that language is now a free preset. Whatever the courts decide, something was taken that was not offered.

I do not think "it is legal" resolves that, and I do not think "it is theft" resolves it either. It is a genuinely new situation and the reflex to force it into an existing category is making the conversation worse.

the practical guidance#

If you are shipping a product that generates images:

• Do not name living artists or active studios in prompts you send on behalf of users, and filter for it. The legal risk is unquantified and the reputational risk is not.
• Understand your provider's indemnification terms. They vary a lot and most people have not read them.
• Provenance metadata (C2PA) costs you nothing to include and will matter more every year.

the thing that will actually change#

Stock photography as a business is finished, and has been finishing for a while. So is a large chunk of low-end commercial illustration — the spot art, the blog headers, the marketing filler.

What is not finished is illustration where the point is that a specific person made it. Miyazaki's films are not valuable because they look like that. They look like that because of what they are.

The model can produce the surface. It has nothing to say.