AI for Software Development: What Changes for Your Team
AI for software development shrinks a team only where the work repeats. The forms it takes, the costs it adds, how to measure it, and what has to be true first.
Read More
An AI governance framework for engineering teams is the written answer to four questions about AI tools: what a model is allowed to see and do, who reviews what it writes, what gets recorded, and who owns the decision. Policies, committees and vendor questionnaires matter only to the extent that they enforce those four answers.
Many frameworks describe principles and councils. What an engineering team needs on a Monday morning is narrower: decisions attached to repositories, pipelines and pull requests. DevLatam places engineers who, in its words, "arrive with the engineering frameworks and playbooks of the ACL group: how code is reviewed, how access is granted, how data is handled, and which data an engineer may share with an AI model." Those are the same four areas, and the decisions below are ones your own organization has to make.
The pressure to make them is rarely a crisis. It is a gradual drift. On its page about AI, security and data, DevLatam puts it this way: "Every model that touches your data adds exposure, and most teams add AI capabilities faster than they review them." DORA's research on AI-assisted software development frames the stakes: AI's primary role is as "an amplifier, magnifying an organization’s existing strengths and weaknesses." A team with clear answers gets its strengths amplified, and a team without them gets its gaps amplified.
An AI governance framework for engineering teams contains four decisions: what a model can see and do, who reviews the code it writes, what is recorded, and who owns the choices. Each one maps to a part of the engineering workflow: repositories and data, pull requests, pipelines and logs, and the org chart.
The first decision is the easiest to test on a real repository, and the fourth is the one that keeps the other three alive.
Start by sorting what a model may read and what it may change. Three lists are enough: which repositories a model may read (for example, public, internal and restricted tiers), which data may never go into a prompt (secrets, customer data, personal data), and which actions an agent may take without asking (read, edit, run commands, reach the network).
Data leakage is the risk behind the second list. A model that can read a repository can also read the credentials, customer records and client code that sit in it, so the rule has to name them. This is the list that answers an AI usage policy question in plain terms: which data an engineer may share with an AI model.
The harder part is enforcement. Some tools offer exclusion rules, and teams reach for them first. Read their limits before you rely on them. GitHub's documentation for Copilot says: "Content exclusion is currently not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors," and that it "is not guaranteed to be respected by third-party MCP servers." That is one vendor's tool, and the point is general: a rule your tools cannot enforce is a request, and your policy should say so. Write down which controls are enforced, which are asked for, and who checks the second kind. Our comparison of four coding agents covers what each tool lets an administrator enforce.
A person who understands the part of the system being changed has to approve it, and that person answers for the approval. The tool that generated the change cannot sign it off, and an AI review assistant is a second pair of eyes for the human, never a replacement.
What the framework adds is a rule about what the reviewer looks for, because generated code fails in its own ways: it can reference a package that does not exist, or carry a credential into a configuration file. Your framework does not need to hold the full checklist. It needs to say that a checklist exists, who maintains it, and how a pull request gets labeled when AI wrote a large share of it, so the team can see where generated code concentrates. DevLatam's secure SDLC guide has the checklist itself. Automated scans for dependencies and secrets then run behind the human review.
Decide what evidence you will want six months from now. Four records are usually enough to reconstruct how a change got in: the approver, the label that marks AI-heavy changes, any exception with its reason and the person who accepted it, and the list of approved tools with the name of whoever approved each one.
Most of this already exists in your pull request history and your pipeline. The framework only has to say where it lives and who can read it, so you can rebuild a decision without chasing the person who made it.
Your organization owns it, and it cannot be delegated to a vendor or a contractor. DevLatam's page on who legally employs the engineers you hire says it plainly: "Someone in your organization has to decide what that access includes, what it excludes, and who reviews it when the work changes. That decision stays inside your company." The same page adds a sentence that applies to every partner: "No partner can take on all of the risk."
In practice, owning the decision means two things. First, a named owner by role, usually an engineering leader working with security, who holds the configuration and the review checklist. The comparison of coding agents explains why: "These tools change month to month. Someone on your team has to own the configuration, or it quietly drifts back to defaults." Second, a review date, so the policy changes when the tools do.
Engineers you bring in from outside follow the same rule. DevLatam's page on being backed by ACL and DataArt says "One engineer joins your team, or as many as the work needs, and they follow your practices." The frameworks the engineer arrives with give a starting point, and your decisions still govern. When the gap is a person, the profile for it is described on the page about AI, security and data engineers, where the security engineer owns "access and data governance around AI systems" and "review of what each new capability exposes." The decision about what they can touch stays with you. Read that division in full on the page about who legally employs them, and the limits of the group's frameworks on the ACL and DataArt page.
Prompt injection is the reason the first decision limits what a model can do as well as what it can read. OWASP defines it as occurring "when user prompts alter the LLM’s behavior or output in unintended ways." The indirect form is the one engineering teams meet: OWASP's entry on prompt injection describes it as happening "when an LLM accepts input from external sources, such as websites or files." An agent that reads a web page or a ticket attachment can be steered by text its user never saw.
OWASP is candid about the limits of prevention: "it is unclear if there are fool-proof methods of prevention for prompt injection." What it recommends instead is limiting the damage: "Enforce privilege control and least privilege access," "Require human approval for high-risk actions," and treat the model "as an untrusted user" when testing trust boundaries. Each of those is a governance decision you have already made if you answered the first two questions. What an agent can reach, and which actions always stop for a person, are the controls that decide how much an injected instruction can do. For LLM security in engineering, that is the practical center of the framework.
Turn them into one page with eight lines, which is the core of an AI acceptable use policy for engineers. Think of it as an engineering skeleton, not an AI policy template with legal language, and send anything contractual through counsel. The eight lines:
Contractors and augmented engineers sign up to the same page. If you write it for your own employees, you have already written it for them, which is the reason to keep it short enough that people read it.
Start with the fourth decision and name the owner this week, because the other three have no one to maintain them until you do. Then answer the first question for your most sensitive repository only. A framework that covers one repository today beats a complete one that exists in a slide deck. If the missing piece is a person who can own the access and review work, that is the profile on the page about AI, security and data.
An AI usage policy, also called an AI acceptable use policy, is the document people read, while the framework is the decisions, owners and records behind it. A policy template gives you the layout. The framework supplies the content: who decided, who checks and what evidence exists.
Someone inside your organization, named by role. Partners and contractors can do the work, but the decision about what a model or an engineer can access stays with your company.
Review it whenever you add a tool or a tool changes what it is allowed to do, and on a fixed date besides. Coding tools change month to month, so a policy without a review date goes out of date quietly.
Learn more about nearshore software development by reading the articles from our blog!
