Does the EU AI Act require or forbid JavaScript obfuscation?
Neither, and the regulation does not contain the word. It is structured around what an AI system does, who is exposed to it, and what the people responsible for it must disclose, document and oversee. The form of the source code that delivers the interface is not a category the text addresses. There is no obligation you discharge by protecting your bundle and none you breach by doing so. What the Act does reach is the front end in three indirect ways: disclosure has to be rendered, machine-readable marking has to survive your build, and you have to be able to say what a given release contained.
Which parts of the regulation actually touch a browser front end?
Three, and only one of them is about the interface itself. The transparency duties are discharged in the user interface your JavaScript renders, so anything that removes or obscures a notice is a live problem. The marking of artificially generated content has to survive bundling and protection, because a marker that a build step destroys stops being detectable. And the documentation and record-keeping expectations assume you can reconstruct and describe a shipped release, which is a build-reproducibility question rather than a legal one. Everything else in the regulation is decided by what your system does, not by how its code is written.
Does protecting our code change how our system is classified?
It does not. Classification follows the purpose the system is put to and the context it operates in: whether it engages in a prohibited practice, whether it falls into one of the listed high-risk uses, whether it interacts with people in a way that triggers disclosure, or whether it is a general-purpose model with its own obligations. None of those tests reference the readability of the code. A protected front end for a high-risk system carries exactly the obligations an unprotected one does, and a protected front end for a minimal-risk system carries exactly as few.
Can obfuscation be used to keep a feature's AI nature less obvious?
It should not be, and that is the sharpest point on this page because it runs against the instinct that brings people here. The transparency duties exist so that a person can tell they are dealing with an AI system, or that a piece of content was generated. Using a build setting to make that harder to establish is working against the purpose of the rule you are subject to. It is also ineffective, because disclosure obligations are assessed on what the user is shown and told, not on what an engineer could read in your bundle. The transformations are neutral here; the intent behind them would not be.
Where does the transparency notice actually live in a protected build?
In the rendered interface, which is precisely the part the code transformations do not affect. Renaming identifiers, moving string literals into a table, encoding literals, flattening control flow and reordering statements all operate on the program. The notice a user reads is produced by that program at run time and is unchanged by any of them. The practical caution is narrower than people expect: if a disclosure string is fetched, feature-flagged or conditionally rendered, then the thing worth testing is that it still renders in the production configuration, which is a testing habit rather than a protection concern.
What about machine-readable marking of generated content?
Treat it as the opposite of a secret, which is the useful reframing. A provenance marker exists to be found by a downstream detector, so anything that makes it harder to locate is a defect rather than a feature. Two practical consequences follow. Marking that matters should be applied where the content is produced, on the server or at the model boundary, rather than by page script an end user controls. And if front-end code does participate in marking, keep it out of runtime guards that can suppress it, and verify it survives your bundler and your protection step by checking a real production artifact rather than a development build.
How does record-keeping interact with per-build polymorphic output?
By default the engine produces different output for the same input on every run, which is a genuine protection property and an inconvenience for anybody who has to state what a release contained. The resolution is the seed setting: supplying a fixed seed makes the same input, options and seed produce byte-identical output, so a release can be rebuilt and compared rather than merely described. The build manifest complements this by recording a hash of each source file and each output file, which is what lets you tie a shipped artifact back to the inputs that produced it.
Does protecting the bundle hide what our front end sends to a model?
Not in any way that survives inspection, and assuming otherwise is the most common mistake in this area. Anything the browser sends is visible in the network panel regardless of how the code that sent it was written, so endpoints, model identifiers, parameters and prompt text all remain observable. If your front end assembles a system prompt, that prompt is in the bundle and is recoverable from the request even if it were not. The structural fix is the same one that applies to API keys: put the model call behind your own server, where the prompt, the routing and the credentials stay.
Where does our source code go when we protect it?
That depends on which path you use, and it is worth answering precisely because it is a processing question your own assessment may need to cover. The hosted service receives the selected JavaScript, protects it and deletes the request file after the run. The Windows desktop application also offers local processing, where the source body stays on the device, and the npm command line has a local mode with the same property. Those local paths still perform an online entitlement check, which does not carry the source. Virtual machine protection remains hosted by design.
Do the runtime defence options create any friction with these duties?
Two are worth a deliberate look, for reasons that are about posture rather than any specific clause. The developer-tools key blocking option cancels every context-menu event on the page, which is a keyboard accessibility cost as well as a transparency-unfriendly signal, and it prevents very little. The integrity guard watches a list of built-in functions and treats replacement as tampering, which can fire on assistive software and on the browser tooling people use to examine a page. Neither is prohibited. Both are choices you should be able to explain if somebody asks why your interface resists examination.
What is the timeline we should be planning against?
The regulation applies in stages rather than all at once, with the prohibited-practice provisions and the literacy expectations arriving first, the general-purpose model obligations following, and the bulk of the high-risk regime landing later still. Because the staging and the national enforcement arrangements are what determine your actual deadlines, that part belongs with your counsel rather than with an engineering page. What does not change with the timeline is the engineering work described here, which is worth doing on its own merits and is cheap to do early.
What is the shortest useful checklist for a front-end team?
Five items. Confirm with counsel which tier your system falls into, because that decides everything else. Verify that every disclosure and label renders correctly in the protected production artifact, not just in a development build. Move any provenance marking that matters to the server side and confirm the front-end path does not destroy it. Adopt a fixed seed and keep the build manifest so a release can be rebuilt and described. And move the model call, its prompt and its credentials behind your own endpoint, which resolves the confidentiality question that brought most teams to this page in the first place.