Is Your Code Safe With a Development Company That Uses AI? Our Rules and How We Check Them

When you outsource development to a company that uses AI, "Is it safe to hand over our code and documents?" is a question worth asking. The answer depends on the rules the company follows when it uses AI, and on how it checks that those rules are kept.

We build much of our work with AI tools such as Claude Code, because it lets us deliver to clients sooner. At the same time, one wrong setting or one API key pasted into an AI tool can leak information. In 2026, data leaks that came in through a contractor or a cloud provider kept happening in Japan. We summarized those incidents and their common weak points in our article on secure by design.

This article answers five questions buyers ask, using the AI tool usage policy in our ISMS (our information security management system under ISO 27001) and the way we check it. At the end we list questions you can ask any development company.

1. Will our code be used to train AI?

Whether an AI service uses your input for training can depend on the plan and the settings, even within the same product. We use only AI tools whose plan or settings keep inputs out of training. Our guide to the ChatGPT and Claude terms of use explains how the terms differ.

Before we start using a new AI service, we check and approve how it handles training, how long it keeps data, where the data is stored and which certifications it holds. When its terms change, we check again.

We also check this in practice. Everyone who uses AI for work reports through a company form that their tools keep inputs out of training. For tools where this depends on a setting, they attach a screenshot of the settings screen. We keep the reports as ISMS records and renew them every year. No work information goes into an account that is not set this way. A buyer cannot see each developer's AI settings, so whether the company checks them is what makes the difference.

2. How much goes into AI?

We put your source code and design documents into an AI tool only if the tool is one we have approved, and only within the scope you have agreed to. At kickoff we explain which tools we will use and what information goes into them, and we record what you agreed to as a decision in the meeting minutes. The record means the agreed scope carries over even if people on the project change.

We make the scope specific, for example: "Repository code and design documents go in. Production data and customer information do not." If your contract or internal rules limit the use of AI, we follow them, and we can also run a project without AI. The scope can be revised during the project, but only with your agreement, which we record again. When a team member is unsure, they ask the project manager rather than decide alone.

3. Could passwords or personal data leak?

Even with tools that exclude training, some information stays out. People sometimes paste things by mistake, so we do not rely on rules alone; settings stop AI from reading these files.

• Credentials. Passwords, API keys and key files must never be entered. Shared repository settings stop AI tools from reading .env files and key files, and nobody may loosen this in their personal settings.
• Personal and business data. Personal data about your customers or users, and production business data, stay out as a rule. If an investigation really needs it, we first replace it with data that cannot identify anyone.
• Production keys. Production keys and service accounts are kept where AI agents cannot reach them.
• Where documents live. Work documents are stored only in our project management system and the company Google Drive. Sharing through public links that anyone can open is not allowed; we share with you by naming the people who can view.

Team members who leave delete all work conversations and documents left in their AI tool accounts.

4. Who checks the code AI writes?

Our team, not the tool, is responsible for the code. Changes written by AI go into a pull request like any other change, and one of our developers reviews them before they are merged. Pushing straight to the production branch is not allowed. AI sometimes writes code that skips authentication or input checks nobody asked for explicitly, so a human review step is essential.

Our policy makes a scan for leaked secrets and a vulnerability audit of the libraries in use required checks in CI (our automated tests and checks). AI never runs the following on its own; a person checks first.

• Deleting or migrating production data
• Anything that affects billing
• Sending data outside, and changing permissions

When AI reads an outside repository or web page, we assume prompt injection can happen, meaning instructions hidden in a document that steer the AI, and we check what it outputs and what it does. When AI suggests a library, we confirm that it exists and check its author and publish date before adopting it. Our article on delegating work to AI explains how we decide what AI is trusted with.

5. How do we know the rules are followed?

Writing rules is easier than making sure everyone keeps following them. We run AI use like any other ISMS control, and the same rules apply to everyone in Tokyo and Nepal.

• Confirmation form. Everyone answers a form with their company account and confirms each rule. We follow up with anyone who has not answered.
• Training. At onboarding and once a year, we train everyone on handling secrets, prompt injection and review, and keep attendance records.
• Evidence. Pull request reviews, CI records and task records show afterwards that people reviewed the code AI wrote.
• Reporting. Anyone who notices an AI tool sending a key or personal data, or doing something suspicious, reports it to the information security manager at once. We record it as an incident, prevent it from recurring, and replace any exposed key immediately.

The policy itself is reviewed once a year and whenever the terms of an AI service we use change. The review also refers to the AI Guidelines for Business (version 1.2) from Japan's Ministry of Economy, Trade and Industry and Ministry of Internal Affairs and Communications.

Questions to ask any development company before you hire them

In February 2025, Japan's Ministry of Economy, Trade and Industry published a contract checklist for using and developing AI. It recommends checking, at the contract stage, how the data you provide to an AI service may be used. The same applies when you hire a development company, and these five questions are worth asking.

• Is your code kept out of AI training by plan or settings, and how is that checked?
• How much of your code and documents will go into AI? Is the scope explained in advance and the agreement recorded?
• Is there a mechanism that keeps passwords and personal data away from AI, enforced by settings and not only by rules?
• Who reviews the code AI writes, and does a person approve releases to production?
• Can they show with records or audits that the rules are followed?

A company that answers specifically and can show its records is easier to trust, even when it uses AI. It is safer still to confirm the answers in the proposal or the contract, not only in conversation.

What this means for your project

We answer the five questions above from the estimate stage onward. If you have your own security rules or AI usage rules, tell us at kickoff, and we will decide the tools and the scope of information around them.

Our AI implementation support page explains how we bring AI into business work. Our approach to information security is set out in our information security policy.

FAQ

Will our code be used to train AI models?

No. We use only AI tools whose plan or settings keep inputs out of training, and everyone reports that state every year, and we keep the records.

What if we do not want AI used on our project?

Tell us at kickoff. We can run the project without AI, or limit how it is used.

Who is responsible for the quality of code AI writes?

We are. Changes written by AI are reviewed by our developers and pass automated checks before they are merged.

Can you follow our own security rules?

Yes. If your contract or your rules set limits on AI use, we follow them.

Summary

Whether it is safe to hand your code to a development company that uses AI depends less on whether it has rules than on whether it can show they are followed. We keep your code out of training, put in only what you agreed to, keep secrets out, and have a person review every change, and we check all four every year as ISMS records.

If you are planning a project, book a free estimate consultation to discuss the approach, including how AI will be used, and a cost estimate with a project manager. If you only have questions about security, you can reach us through our contact page.

Related articles and pages

• ChatGPT and Claude terms of use: training, plans and deletion requests
• What is secure by design? Lessons from Japan's 2026 breaches
• Tokyo system development company: from requirements to operation
• AI implementation support: from PoC to production
• Information security policy: how we approach information security
• Free estimate consultation: talk to a project manager about scope and cost

Sources

• Ministry of Economy, Trade and Industry, "Contract checklist for the use and development of AI", 18 February 2025 (Japanese)
• Ministry of Internal Affairs and Communications, "AI Guidelines for Business (version 1.2)", 31 March 2026 (Japanese)
• Anthropic, "Updates to Consumer Terms and Privacy Policy", 28 August 2025
• Anthropic, "Commercial Terms of Service", effective 17 June 2025