A controller pasted "just to find the bug", an access key forgotten on line 12: AI code review often leaks through harmless-looking habits. Six common mistakes, and how to work without them.
Tuesday, 4.30 pm. An integration test has been failing since the morning, and the release is scheduled for Thursday. The developer selects the whole controller, four hundred lines, pastes it into a consumer AI tool and types: "find the bug". The answer comes back, and it is right. Nobody notices that line 12 held an access key to the staging environment, that the comments named the client, and that the discount calculation rule, the one the team spent two years refining, now sits with a provider nobody chose.
This is the mistake we see most often: not a spectacular lapse, but a copy and paste done under pressure. And yet AI is a very good code reviewer. You just need to know what you are giving it, and where.
Code written for an employer or a client generally does not belong to you. It falls under trade secrets, which the law protects in Switzerland as across Europe; it is often covered by a confidentiality clause in the employment or service contract; and the company's IT policy frequently forbids sending code to an unapproved service. For a contractor, the code sometimes belongs to the client, who never authorised it to leave.
On top of that comes the personal data that slips into code: test datasets copied from production, error logs, addresses in fixtures. That data falls under the GDPR or the Swiss Federal Act on Data Protection (FADP), whatever the nature of the project.
A single file looks harmless. But it is often the file that matters: the pricing algorithm, the logic of a recommendation engine, the workaround for a library's limitation. Once pasted into a consumer AI tool, it sits with a third party that may keep the history, and whose provider may be subject to foreign laws that require it to hand over what it holds.
The fix: do the review on a confidential model. In IA Confidential, the local and specialised models are open models installed on servers in Switzerland, under the Swiss Federal Act on Data Protection and outside the reach of the CLOUD Act; they pass nothing on to third parties. The model is chosen automatically or manually, and for a code review, a confidential model is the right place to start.
Hard-coded access keys, a database connection string, a third-party service token, an environment configuration file attached "for context", a stack trace containing a user's email address. People paste them without seeing them, because they are looking for a bug, not a leak.
The fix: remove secrets before sending anything, even to a confidential tool. A review never needs the real value of a key: replace it with [API_KEY], and real data with made-up values. If a key has already gone somewhere, rotate it. The guide on what not to paste into AI covers access credentials in detail. The simplest request shows you can do without them:
Here is a PHP stack trace and the method that triggers it. I have replaced the credentials and the data with fictitious values. Explain the likely cause in three sentences, then suggest the smallest possible fix.
Renaming calculateClientXDiscount to f1, removing the company name from the comments: it feels as if the code has been made anonymous. But what gives proprietary code its value is its logic, and that stays intact. Table names, internal domains and error messages are often enough to recognise the project.
IA Confidential's Confidentiality filter does not claim to do better. When you choose an external model, it first detects sensitive data and lets you decide: answer with a confidential model, message unchanged; send an anonymised version, which you can review and correct; or send it as is. For an attachment, only the useful extracts go out, pseudonymised. But what it replaces is data that identifies: a name, an address, an identifier. Not an algorithm.
The fix: tell two kinds of question apart. "Why is this sort slow?" about your billing module stays on a confidential model. "How does optimistic locking work in general?" can go to an external model, without your code. For the names you never want to see leave, such as the client's name, the project's code name or an internal domain, write them into the anonymisation instructions in the Privacy panel: these are precisely the things no detector can guess on its own. The guide on anonymisation and pseudonymisation explains the difference.
Two opposite excesses. Either you attach a single file, and the AI makes up the behaviour of the classes it cannot see. Or you give it the project root "so it has everything", along with the production configuration, the database backups and the deployment scripts.
The fix: give the useful context, and only that. On a computer, with Chrome, Edge or Opera, you can add up to ten folders from your machine to a space, with rights set per folder: Search, Read, Write. For a review, add the folder of the module concerned rather than the root, without the Write right, and tick the "Confidential models" option: the folder is then never sent to an external model. With a signed-in account, the assistant automatically finds the passages relevant to your question. On another browser, attach the files you need to your message: they are read in your browser, and none is kept on our servers.
Without criteria, the review is generic: style remarks, a naming tip, a suggestion to add comments. The real issue (a memory leak, a query inside a loop, an injection flaw) slips through the cracks.
The fix: set the framework once, then be specific with each request. Create a "Development" space for each project: it offers examples for reading, fixing and writing code, and detailed answers. In the Assistant tab, the space instructions set the language and its version, the framework, your conventions and what is out of scope; they take precedence over your general preferences. Each request then says what you are looking for:
Review the import method below, which is called on files of 50,000 lines. I don't want style remarks. Look only for: queries executed inside a loop, full loads into memory, and cases where one invalid line stops the whole import. For each point, quote the line and estimate the effect on a large file.
AI gets things wrong with confidence. It invents a method that does not exist in your version of the library, suggests a fix that makes the test pass without addressing the cause, declares code "safe" when a flaw has escaped it. An AI code review is not a security audit, and a fix accepted in a hurry ends up in production on Thursday.
The fix: make it explain itself, and check. Ask for line numbers, explicit assumptions, and what it could not see. Then run every fix through your tests and through the team's usual human review. The most thorough request looks like this:
Here is the diff of a pull request that changes our token authentication, with the two files it touches. Do a security review: access control, input validation, error handling, token comparison. For each risk, give the line, a concrete attack scenario and the minimal fix. Then list what you could not check because you cannot see the rest of the code, and suggest three tests that would prove the fix works.
Responsibility for merged code stays with the team that merges it.
With a confidential model, your code leaves your machine to be processed on servers located in Switzerland, and then nothing is kept on our side. A folder added with the "Confidential models" option is never sent to an external model, and the index used to find passages in it stays in the folder, on your computer. Attached files are read in your browser.
With an external model, you decide what goes out, once the filter has run: an anonymised version, pseudonymised extracts, or the message as it is if you accept that. Your personal profile, for its part, is never sent to an external model. Bear in mind that anonymisation masks names, not logic: code whose algorithm is the secret stays on the confidential models.
The history of your conversations, code snippets included, lives in your browser and nowhere else. On a shared workstation or a common staging machine, anyone using the same session can read it: work in a personal session and sign out when you leave. And a secret removed from the message is only protected if it is also removed from your repository.
If your team is still hesitant about allowing AI, the arguments in the guide on using AI at work safely apply just as well to a development team. To try it on a low-stakes module, secrets removed: open the chat.
