Skip to content

AI at the company level

Everything in Working with AI as a team still applies — a company is teams, and the shared-foundation habits scale up. What a company adds on top is guardrails: the questions a single team can leave informal but an organization can't. What is allowed? What data may leave the building? What can an agent do on its own, and where is that contained? At company scale these need answers written down, not norms carried in people's heads.

Who this is for: engineering leads, security, and anyone setting or enforcing AI policy for more than one team. If you're a solo developer or a single team, most of this is lighter-weight for you — but the questions are the same, and it's cheaper to answer them early than to retrofit them after an incident.

Policy, data boundaries, sandboxing, and config you deploy rather than ask for — 2 min 23 s.

From team norms to company policy

A team can run on shared understanding. A company needs a written AI usage policy so the answer is the same across teams that don't talk daily. Keep it short and concrete — a policy no one reads protects no one. It should state at minimum:

  • What's approved. Which tools and which models are sanctioned for company work, and how someone requests a new one.
  • What's allowed where. Which categories of work can use AI freely, and which need extra care (e.g. anything touching customer data or security-critical code).
  • What must never go into a prompt. The hard lines — secrets, credentials, personal data, anything under a contractual confidentiality boundary.

Write it as a living document, owned like any other shared artifact (see the team foundation), not a one-time PDF that goes stale.

Privacy and data boundaries

The core question is simple to state and easy to get wrong: what data is allowed to leave the building, and to where? Every prompt sent to a hosted model is data leaving your infrastructure. That may be perfectly fine — or a violation — depending on the data and the destination.

  • Classify what's sensitive. Source code, secrets, customer data, and unreleased plans each carry different risk. The policy should say plainly what may be shared with a hosted model and what may not.
  • Know your provider's data handling. Whether prompts are retained or used for training is a contractual question — check the provider's privacy and enterprise terms rather than assuming.
  • Weigh hosted vs. self-hosted. A hosted API is simpler and usually more capable; a self-hosted or private-deployment model keeps data in-house at some capability and operational cost. This is a trade-off to decide deliberately per data class, not a default to stumble into.

Permissions and sandboxing at scale

The mechanics of what an agent is allowed to do — permission modes, allowlists, and the sandbox that contains an autonomous run — are covered in Security, permissions and sandboxing; the glossary defines permission modes, sandboxing, and prompt injection. At company scale the question shifts from "what do I allow?" to "what's the safe default for everyone?"

  • Set conservative org-wide defaults so a new project or a new hire starts safe, and loosening is a deliberate, visible choice rather than the starting state.
  • Require a sandbox for autonomous or unattended agent runs and for anything touching untrusted input — the blast radius of a mistake (or a prompt injection — OWASP's top LLM risk) should be contained by construction, not by hoping the agent behaves.
  • Treat elevated permissions the way you treat production access: granted narrowly, for a reason, and reviewable.

Managed, org-wide configuration

Policy that relies on every developer configuring their machine correctly will fail on the first person who doesn't. The scalable version is configuration the organization deploys, not asks for. As noted in MCP and config, tooling supports an IT-deployed, managed policy file (backed by the Claude Code IAM and settings references) that sets org-wide rules centrally, and shared MCP config can be distributed rather than hand-configured.

The principle: make the safe, correct setup the one people get by default. The more of your policy is enforced by managed configuration instead of documentation, the less it depends on everyone remembering to do the right thing.

Governance and rollout

The AI landscape moves fast, so the goal isn't a fixed rulebook — it's a lightweight process for changing the rules well:

  • A path to approve new tools. When someone wants a new model, plugin, or MCP server, there should be a known, quick way to evaluate and sanction it — friction low enough that people use the path instead of routing around it.
  • A clear owner. Someone (or a small group) owns the AI policy and its evolution, the same way the team foundation has an owner.
  • Roll out like any change. New policy and new managed defaults deserve a heads-up and a rollout, not a silent flip that surprises everyone mid-task.

Quick checklist

  • A written, living AI usage policy: approved tools, allowed uses, hard "never" lines
  • Data classes are defined, with clear rules on what may reach a hosted model
  • Provider data-handling terms are understood; hosted vs. self-hosted decided per data class
  • Conservative org-wide permission defaults; sandbox required for autonomous or untrusted runs
  • Policy enforced by managed, IT-deployed configuration where possible — not left to each machine
  • A lightweight, known path to evaluate and approve new tools
  • The policy has an explicit owner and is rolled out like any other change