Move faster with Claude Code, Copilot, Codex and other AI tools without losing control of code, data, security or customer commitments. AI coding tools are rapidly becoming part of the normal software development environment. Developers may use Claude Code, GitHub Copilot, Codex, Cursor and other AI-enabled tools to understand codebases, generate and modify code, troubleshoot problems, create tests and automate development tasks.
The opportunity is significant. But the governance question changes when an AI tool can read repositories, access files, execute commands, interact with development infrastructure or connect to other systems through tools such as MCP.
The relevant question is therefore often no longer: Can our developers use AI?
It is: Which uses can we approve, under what conditions, and what controls do we need?
Sharp Cookie Advisors helps technology organisations answer that question and translate the answer into practical rules for Engineering, Security, Legal and management.
We do not begin with a generic AI policy.We start by understanding how the tools are actually being used.
We then identify where the technical setup creates material legal, security, regulatory or commercial consequences. The objective is not to make software development slower. It is to create a structure that allows Engineering to use AI with clear boundaries and fewer unresolved questions.
Engineering wants to deploy an AI coding tool more broadly and Security, Legal or management needs a defensible basis for approving the use. We help identify which questions matter before the rollout and which controls can reasonably be implemented.
Many organisations discover that AI adoption has happened before formal governance. Different teams may use different accounts, plans, models, extensions and configurations.
The first task is then not to write another policy. It is to understand the current position and decide what should be permitted going forward.
An assistant that suggests code presents a different risk profile from an agent that can read repositories, execute commands, interact with ticketing systems, query documentation or invoke external services.
As AI becomes more agentic, access, authorisation, human control and auditability become increasingly important.
Your customers may ask whether AI is used in development, whether their information can be exposed to AI suppliers, which subprocessors are involved, where information is processed and which security controls apply.
We help connect the answers given by Engineering and Security with the commitments made in customer agreements, DPAs and security documentation.
For organisations subject to GDPR, cybersecurity requirements, NIS2-related obligations or sector-specific regulation, use of external AI tools may need to fit into existing risk management, supplier governance, information security and accountability processes.
The objective is normally to integrate AI into those processes rather than creating an entirely separate compliance structure.
The scope depends on the tools, environment and business.
A typical review may cover the following areas.
We establish what the AI tools can actually do in your development environment.
This may include:
We are not replacing your security engineers or performing a penetration test.
Our role is to understand the technical setup sufficiently to identify where architecture and configuration create legal, regulatory, supplier or customer consequences.
The prompt typed by the developer is only one part of the picture. Depending on the service and configuration, an AI tool may process source code, files, logs, error messages, repository information, metadata, telemetry or information retrieved from connected systems.
We help establish which information may be processed and what that means for your organisation. Particular attention may be required where development or support processes can expose:
The question is not simply whether the organisation intends to send sensitive information to an AI service. It is whether the development workflow makes that possible.
Enterprise versions of AI tools can differ materially from consumer offerings. Configuration, contractual commitments, data use, retention, subprocessors, hosting arrangements and administrative controls may all matter. Depending on the engagement, we can review issues such as:
The purpose is not to negotiate every clause in isolation. It is to determine whether the supplier position is appropriate for the intended use.
Your organisation may already have contractual obligations that affect how AI tools can be used internally. Enterprise and regulated customers frequently impose requirements concerning confidentiality, security, processing locations, subcontractors, customer data, development practices and incident management. An AI tool used internally by Engineering may therefore create a customer-contract issue even though the tool is never part of the customer-facing product.
We help identify where AI use intersects with commitments already made to customers and what needs to be addressed.
There is rarely one regulation that provides the complete answer. Depending on the organisation and use case, relevant considerations may include:
We focus on requirements that materially affect the intended use. Not every developer tool requires a major regulatory project. The objective is to establish where the actual boundaries are and build proportionate controls around them.
A policy alone rarely solves the problem. The output should be usable by the people making day-to-day decisions.
Depending on the organisation, practical controls may include:
Approved tools and account types
Which AI services, enterprise plans and configurations may be used?
Permitted use cases
What can developers use the tools for without additional approval?
Data rules
Which categories of information must not be submitted or exposed?
Access and permissions
Which repositories, systems and tools may an AI agent interact with?
Human approval
Which actions require review before execution, merge or deployment?
Supplier approval
What must be checked before a new AI service is introduced?
Logging and accountability
What information needs to be retained to understand how the tool has been used?
Ownership
Who can approve new tools, exceptions and higher-risk use cases?
The aim is a governance model that Engineering can actually work with.
For many organisations, the easiest starting point is a defined AI Engineering Readiness Review. This gives management, Engineering and Security a senior independent assessment of the current or proposed use of AI development tools. We agree the precise scope before starting.
A typical review may include:
The result is intended to support decisions.
Not to produce an abstract legal memorandum.
Some organisations only need an independent review. Others want help putting the recommendations into practice.
We can support the work at three levels.
A defined assessment with clear questions, deliverables and priorities. For a suitable engagement, we will normally agree a fixed scope and fixed fee before substantive work begins.
We can help translate the assessment into practical documentation and controls, including:
AI development tools are changing quickly. Organisations may therefore need a senior adviser who can help assess new tools, suppliers, customer questions and use cases without starting a new compliance project each time.
We can provide ongoing support to CTO, CIO, CISO, Engineering, Legal, DPO and management teams as the organisation's use of AI develops.
Tell us which tools you use or plan to introduce, how your development environment works at a high level and what decision you need to make. There is no obligation from the first contact.
We identify the relevant materials, people and questions. For a defined readiness review, we normally agree the scope, deliverables and fee before starting.
We meet the people who understand the development environment. Depending on the assignment, this may include Engineering, Security, Platform, Architecture, Legal, Privacy or Procurement. We need to understand how the technology works in practice, not merely how it is described in a policy.
We identify the issues that materially affect the intended use, explain the available options and prioritise the required controls.
Your organisation can implement the recommendations internally or ask us to support selected parts of the work.
Our work is particularly relevant for:
We typically work with people responsible for making the technology usable in the real business environment:
CTO, CIO, CISO, Chief Architect, VP Engineering, Head of Engineering, Platform teams, Legal, DPO, Procurement and management.
AI in software development sits between technology, information security, data protection, supplier management and customer contracts. That intersection is where we work.
Sharp Cookie Advisors advises technology businesses on AI, software and SaaS, cloud services, GDPR and data protection, cybersecurity-related regulatory matters and complex technology agreements.
Our role is not to tell Engineering to stop using useful technology because the regulatory landscape is complicated. It is to understand the technology and the business well enough to identify the issues that matter, establish workable boundaries and help the organisation move forward.
Often, yes – but a policy is rarely enough on its own.
The organisation also needs to decide which tools and accounts are approved, which data may be processed, which systems agents may access, what requires human approval and who is responsible for approving new use cases. The policy should reflect those decisions rather than substitute for them.
There is no useful yes-or-no answer at product-name level.
The relevant assessment depends on the product version, configuration, data involved, integrations, permissions, contractual terms and intended use. An enterprise deployment used against selected repositories can therefore require a different assessment from an individual developer using a consumer account with broader access.
That depends on the information, your role in relation to the customer, the supplier setup, applicable contracts and the relevant legal requirements. For SaaS suppliers and processors, customer agreements and DPAs are often as important as the AI tool's own terms.
An AI coding tool is not automatically a separate “NIS2 system”.
However, for organisations subject to NIS2-related cybersecurity requirements, the use of external AI services can become relevant to security risk management, supplier governance, access controls and other existing cybersecurity processes. The analysis should therefore start with the organisation and the actual use case.
It depends on whether personal data is processed, for whose purposes and on whose instructions. Where a company acting as a processor allows another supplier to process customer personal data on its behalf, subprocessor requirements may become relevant. The correct role should be established from the actual data flow rather than assumed from the product category.
Not every use of an AI coding tool requires a major classification exercise.
The relevant obligations depend on the system, the organisation's role and how the AI is used. The practical starting point is to understand the use case and determine which AI Act requirements, if any, materially affect it.
Yes.
Where an organisation already has established information-security or AI-management processes, we normally prefer to integrate the relevant AI controls into those processes rather than create unnecessary parallel governance.
We can help identify the legal and governance requirements and work with the people responsible for the organisation's management system.
You do not need to diagnose the legal issue before contacting us. Tell us which AI tools you are using or considering, what your developers need them to do and what is currently preventing you from moving forward.
We can determine whether an AI Engineering Readiness Review is the appropriate starting point and propose a clear scope and cost before substantive work begins.
If you are considering Claude Code, Copilot, Codex or other AI tools in your development environment, contact us to discuss the setup, risks and controls that matter for your organisation.
