Claude Adoption & Governance Guide

This is the reference for introducing Claude as a controlled company platform rather than a loose collection of personal tools. It is the "how we run Claude" document; the Onboarding page is the "how I personally start" document, and the Training Plan is the structured rollout of trainings.

Guide vs. binding policy

This guide explains the reasoning and the practice. The binding internal policy (the formal "Claude AI Unternehmensrichtlinie" with approval sign-offs and the data-protection assessment) is the authoritative document for obligations and enforcement. Where this guide and the policy differ, the policy wins.

1. The four-layer operating model

For a company, Claude is not just a chat tool. It is a combination of Claude for Work / Enterprise, the Claude Platform (API), Claude Code, Cowork, Projects, Artifacts, Skills, Connectors, and Plugins. Introducing it well is an operating model with four layers:

Layer 1  Governance & secure base   →  Enterprise: SSO, SCIM, roles, audit logs, retention
Layer 2  Structured team work       →  Projects, Skills, Artifacts
Layer 3  Controlled extension       →  Connectors, Plugins (only after review)
Layer 4  Technical integration      →  Platform / API, automation

Whoever only "switches Claude on" gets island usage. Whoever introduces it as a platform with rules, standards, and approved workflows gets reproducible productivity.

2. The surface map

Surface	What it is	Primary use
Claude Enterprise	The secure org environment (SSO, SCIM, audit logs, retention, Compliance & Analytics API)	The base for everything
Platform / API	Developer path for custom apps, assistants, automation	Embedding Claude in internal systems
Claude Code	Agentic coding tool (reads/edits code, runs commands)	Development, in approved repos
Cowork	Agentic, multi-step knowledge work over local files	Document synthesis, reports, research
Projects	Persistent workspaces bundling context, files, instructions	Recurring team work
Artifacts	Generated, reusable content and small apps	Deliverables, prototypes, dashboards
Connectors	Links to external data/tools via MCP	GitHub, Drive, M365, Slack, internal sources
Plugins	Packaged bundles of Skills, agents, hooks, MCP servers	Distributing standard setups to teams
Skills	Reusable instruction/script/resource packages	Standardized, repeatable tasks

For where Chat, Projects, and Claude Code differ in daily work, see the Surfaces & Features Guide. For Artifacts specifically, see the Artifacts Guide.

3. What to decide first

Before any technical setup, settle internally:

Which data classes Claude may see (see the traffic light in section 5)
Which teams get which functions
Whether you only use the Claude apps or also build on the API
Which decisions always stay with a human

This matters because functions like Cowork, web search, Connectors, and Plugins meaningfully widen the data flow and reach of the system. Enterprise gives you strong controls, but only if you decide consciously rather than enabling everything at once.

4. The phased rollout

Introduce capabilities in order, not all at once:

Phase	Focus	Contents
1 – Governance & base	Make it safe	Enterprise, SSO + Domain Capture, SCIM/JIT, role model, retention, audit logs, DPA / Trust Center review
2 – Department pilots	Prove value	1–2 Projects, 2–3 Skills, only necessary Connectors, no free plugins (Sales, Marketing, Support)
3 – Claude Code pilot	Controlled dev	1–2 teams, defined repos, isolated environments, mandatory review
4 – Cowork pilot	Knowledge work	PMO, Sales Ops, Marketing Ops on defined use cases
5 – Scale	Institutionalize	Central Skill catalog, plugin governance, API integrations, regular audits and policy review

Recommended sequence in one line: Enterprise first → Teams & Projects → Skills → Connectors → Cowork → Claude Code broadly only with technical governance.

5. Data classification & DSGVO practice

Every input is classified before use:

Light	Class	Handling
🟢 Green	Public or uncritical internal information	Usable
🟡 Yellow	Internal information with limited confidentiality	Only in approved Claude environments
🔴 Red	Patient/health data, dental-practice customer data, secrets and credentials, confidential contracts, security-relevant configs, non-approved production data	Prohibited, or a separate documented approval process

Professional secrecy is non-negotiable

Our customers are bound by professional secrecy (§ 203 StGB). Patient data, health data, diagnoses, and findings must never be entered or generated — not even paraphrased. No personal data goes into any output that will be shared externally.

Before productive use, check at minimum: legal basis and purpose limitation, DPA/AVV with Anthropic, the subprocessor list, storage location and transfer, retention policy, deletion/export processes, separation of sensitive data classes, and the employee acceptable-use policy. Anthropic publishes DPA, subprocessor information, and compliance documents (SOC 2 Type II, ISO 27001, ISO 42001, HIPAA offerings) in its Trust Center.

6. Security baseline

Treat Claude like any other SaaS platform with AI capability:

Least privilege — restrict rights to files, repos, connectors, plugins, and external systems
Access only via company identity — SSO, Domain Capture, SCIM/JIT
Clear data classification — the traffic light, applied consistently
Switch off high-risk functions until a use case is approved (web search, Cowork, plugins)
Logged usage — audit logs, and plan the Compliance/Analytics API into your security/BI processes
Regular role reviews
DPA / contract review and subprocessor review
Data-protection sign-off by Data Protection / Legal

Control the risk, don't fantasize it away

Even with Enterprise and Claude Code, residual risk remains. The honest internal framing is control the risk, not promise there is none.

7. Team operating models

The best structure is usually not one big workspace for everything, but one Enterprise org, role/group control, shared base Skills, project-specific Projects, only team-relevant Connectors, and few reviewed Plugins.

Sales

Projects: Key Accounts, Offers, Quarterly Pipeline
Skills: offer structure, discovery questions, objection handling, follow-up format
Connectors: CRM-adjacent sources, email, document stores
Cowork: evaluate tenders, assemble offer building blocks
Artifacts: deal-health dashboard, objection matrix

Example: a Skill "create enterprise offer" forces a fixed structure (customer goal → current situation → solution → ROI → risks → next steps), so several salespeople produce consistent drafts.

IT / Development

Claude Code for pilot then productive teams
Connectors/GitHub only for approved repos
Plugins for internal standards
Skills: architecture decisions, PR checklists, security review, release notes

Example: a plugin "company-engineering-standard" bundles a PR-review agent, a config-change hook, an MCP for approved doc sources, an "ADR" Skill, and a /prepare-pr command — every team gets the same standards.

Marketing

Projects by campaign, product line, or region
Skills: brand voice, tone, approval logic, landing-page outline
Artifacts: campaign prototypes, microsites
Cowork: market and content synthesis

Management

Projects: board, strategy, monthly steering, OKRs
Cowork: report consolidation
Skills: management templates (e.g. a "monthly ops review" with a fixed structure)
Artifacts: interactive decision overviews
Very restrictive connector approval

Support

Projects per product or support line
Skills: answer style, escalation logic, macros, summaries
Connectors: knowledge base, ticket context, product docs (never patient/practice data)

8. Claude Code — safe use

Claude Code is an agentic coding system that can read code, change it across files, run commands, and run tests. Do not open it to all developers at once. Stage the rollout:

Stage A  Pilot team        →  2–5 experienced devs, one uncritical repo
Stage B  Secured env       →  dev containers / sandboxed local / segmented repos
Stage C  Team standards    →  shared CLAUDE.md, review rules, branch conventions, tests
Stage D  Governance        →  managed settings, audit, plugins/MCPs only after review

Best practices:

Always a human review before merge/deploy. You decide what ships.
Only the rights actually needed — repo, files, shell, network as narrow as possible; use project-scoped permission settings.
Work in isolated environments — dev containers / sandbox reduce filesystem and network risk.
Do not run --dangerously-skip-permissions in sensitive contexts. Prefer sandboxing or the guarded auto-mode.
Hard quality gates — no direct push to main, tests green, security checks run, PR review mandatory.
Only approved plugins/MCPs. Anthropic does not audit third-party MCP servers — use only trusted or self-operated ones.

GitHub access: connect only selected repos, separate productive/sensitive repos, prefer service accounts, read-only by default with write only when necessary, and define repository classes (open / internal / strictly confidential).

9. Cowork — safe use

Cowork is not a chat assistant; it is a system for multi-step knowledge work over local files, folders, and apps that returns finished deliverables.

Good for: document synthesis, file organization, reports from source material, extraction from contracts/PDFs/lists, research dossiers, recurring knowledge work in Operations, Finance, HR, Legal, PMO.

Not for: high-stakes approval decisions, final contract judgments without human control, or processes with uncontrolled external connections.

Cowork and regulated workloads

Cowork has specific limits: its activity is not fully captured in Audit Logs, the Compliance API, or data exports, and Anthropic advises against using it for regulated workloads. Given our regulatory environment (TrinkwV, biocide law, professional secrecy), keep Cowork to clearly non-regulated, internal knowledge work, with mandatory human sign-off.

How to run it: enable for 1–2 suitable teams first, keep web search off until use cases are approved, allow only reviewed plugins, define input folders and output formats, and log and review Cowork tasks. Phrase tasks by outcome: "From these 14 offer documents, build a comparison matrix with risks, prices, deadlines, and open points."

A good Skill is specific and repeatable, not "do marketing better." Examples: "create German B2B LinkedIn posts in our brand guide," "analyze incoming tenders for knock-out criteria," "produce ADRs in our template."

Skill classes: Corporate (writing style, brand, data-protection hints) · Team (Sales, Marketing, Support, Dev) · Workflow (offer analysis, report creation, ticket triage) · System (file formats, structured output, checklists).

Each Skill carries: name, purpose, business owner, version, allowed data classes, scope, review date, test examples.

Sharing path: test locally → team pilot → org-wide provisioning (requires Skills plus code execution / file creation enabled) → versioning and a named owner → document every release. Share externally only through separate public plugins or open-source repos that contain no internal content — never directly from the internal workspace.

11. Practical productivity layer

Governance keeps usage safe; these habits make it genuinely effective. Fold them into team Skills and Project instructions so the whole team benefits.

Outcome-first prompting. State the deliverable, audience, tone, length, and constraints. Vague input is the main cause of weak output — not a model limit.
Sound like the company, not like generic AI. Seed brand voice and example texts into a Skill or Project; tell Claude what to avoid (filler, buzzwords). This is exactly what brand-voice Skills are for.
Iterate in small steps and use Artifacts versioning to keep a clean trail.
Reuse context with Projects instead of re-explaining every time.
Avoid hitting limits by working in focused Projects, keeping prompts tight, and splitting very large tasks — rather than pasting everything into one giant message.
Use the right format: ask for a Mermaid diagram, a Markdown table, a slide outline, or a spreadsheet when that is the real deliverable.

External learning resource

claude101.com offers short practical lessons (prompting, tone, Cowork, Skills, Connectors, slides, Excel) that complement this guide. Use it as background learning; the governance rules here always take precedence.

12. Roles & responsibilities

Role	Responsibility
Management	Strategic approval, resources, naming the owners
IT / Platform	Technical setup, identity, operations, API/integration management
Information Security	Security review, role/permission model, connector/plugin approvals, controls
Data Protection / Legal	DPA, data-flow and transfer assessment, approvals for sensitive processing
Departments	Define use cases, name Skill/Project owners, check results
Users	Use per policy, careful input and review, report incidents

13. Allowed / not allowed (summary)

Allowed: drafts, summaries, knowledge prep; research and document synthesis; offer/marketing/support templates; code analysis and dev support in approved repos; team standards via Skills; defined Cowork workflows; API-based internal assistants.

Not allowed: private shadow use with company data; entering secrets/credentials/tokens without approval; uncontrolled plugins/MCPs/connectors; productive decisions without human review; unsafe Claude Code configs in sensitive environments; processing data against the classification.

1. The four-layer operating model​

2. The surface map​

3. What to decide first​

4. The phased rollout​

5. Data classification & DSGVO practice​

6. Security baseline​

7. Team operating models​

Sales​

IT / Development​

Marketing​

Management​

Support​

8. Claude Code — safe use​

9. Cowork — safe use​

10. Skills — build & share​

11. Practical productivity layer​

12. Roles & responsibilities​

13. Allowed / not allowed (summary)​

Further reading​