AI Project Policy

Appearance

Experimentation Boundaries ​

Purpose ​

These boundaries help employees understand three paths:

  1. continue experimenting;
  2. ask Dev for guidance or resources;
  3. hand the work off to the responsible domain specialists.

The goal is to make AI experimentation easy while giving promising ideas a clear path to become supported company capabilities.

Continue experimenting ​

You may continue experimenting when all of the following are true:

  • the work is exploratory, educational, or prototype-oriented;
  • the AI tool does not connect to production systems;
  • the AI tool does not receive sensitive data;
  • the AI output does not directly trigger production actions;
  • the experiment can be deleted or abandoned without operational impact;
  • access is through approved company resources or otherwise permitted tools.

Examples:

  • testing prompt patterns against synthetic data;
  • summarizing public documentation;
  • generating sample code that is reviewed before use;
  • comparing model behavior on non-sensitive examples;
  • building a local proof of concept with mock APIs;
  • exploring whether a workflow is worth proposing as a formal project.

Ask for guidance or resources ​

Some experiments can continue, but may benefit from Dev guidance or resources.

Contact Dev when you want help with:

  • choosing a model;
  • choosing a tool;
  • using company inference resources;
  • using AI-compatible search or fetch tools;
  • using vector databases;
  • designing a prototype;
  • writing a product specification;
  • understanding whether data is sensitive;
  • deciding whether the idea is still an experiment or needs handoff.

Guidance is available even when it is not required. Dev is happy to hear what employees are exploring and help shape the next step.

Use by multiple teams or recurring automation does not require specialist guidance by itself. It needs guidance only when it also involves sensitive data, production systems, meaningful capacity impact, unapproved tools, specialized access, or real-world impact.

When experimentation must become managed work ​

Some uses require ownership by the domain specialists responsible for the affected systems, data, and operations.

Start production handoff when the AI workflow will:

  • connect to production systems or production networks;
  • read from or write to production databases, queues, object stores, APIs, logs, or admin consoles;
  • process customer data, employee data, credentials, secrets, regulated data, or confidential business data;
  • make or recommend customer-impacting decisions without approved review controls;
  • take autonomous action against production systems;
  • change infrastructure, permissions, firewall rules, deployments, financial settings, or security controls;
  • send company-sensitive material to unapproved external AI services;
  • use AI output as the sole authority for security enforcement or production operations decisions;
  • use AI in HR, legal, compliance, finance, or customer eligibility workflows without involving the responsible business owner and required specialist teams;
  • bypass existing SDLC, change management, access management, or incident response processes.

Start the handoff process before the work continues into production systems, sensitive data, or real-world impact.

Sharing prototypes ​

We expect employees to share prototypes with the same care and professionalism they bring to the rest of their work.

When sharing a prototype, it is helpful to include enough context so other people understand how to use it safely. Useful context may include:

  • whether the prototype is experimental or production-ready;
  • what data is appropriate to use with it;
  • whether it stores prompts, files, responses, or embeddings;
  • who to contact with questions;
  • what would need to change before production use.

This is guidance, not a formal labeling requirement.

Use the safest useful data ​

Experiments should use the least sensitive data that can answer the question.

Preferred test data, in order:

  1. synthetic data;
  2. public data;
  3. approved non-sensitive internal data;
  4. anonymized or aggregated internal data approved for this purpose;
  5. sampled internal data only after review;
  6. production sensitive data only after production handoff and approval.