Microsoft Frontier gives organizations early access to emerging Copilot features before general availability. Admins can target users, and the organization can evaluate readiness and provide feedback. That makes previews useful instruments for strategic learning.

It does not make them production services. Microsoft’s Online Services terms state that previews may not have the corresponding SLA or support and may change, end or never reach general availability. Product documentation can also change rapidly. The enterprise question is therefore not “Can we switch it on?” but “Can we learn what we need without creating an unacceptable dependency?”

Apply six gates before access

1. Learning objective

State the decision the preview will inform. Examples include whether a capability reduces preparation time, whether users can complete a particular task or whether a new authority model is workable. “Explore AI” is not measurable.

Define success, failure and the evidence needed for a later production business case. If no decision will change, the preview has no justified exposure.

2. Audience and authority

Name participants, roles and permitted actions. Limit who can invite others, create assets or connect additional services. Separate observation, content generation and actions that change business state.

3. Data and provider boundary

Specify permitted data classes, locations, retention expectations and prohibited content. Confirm which entity operates the model or service and which terms apply. Preview status alone does not answer data handling; Microsoft explicitly distinguishes release readiness from provider and processing arrangements for preview models.

4. Contract, support and cost

Record licensing prerequisites, usage-based charges, supplemental terms, support route, SLA status and known limits. Decide who watches consumption and what stops the experiment at its budget boundary.

5. Reversibility and continuity

Explain how access, identities, connectors, generated assets and stored data will be removed or migrated. No critical operation should depend on the preview unless an acceptable fallback exists. Test the fallback before the team becomes reliant on the feature.

6. Exit and graduation

Set an end date, review owner and decision options. Graduation is not automatic when users like the tool. It requires current terms, security evidence, operating ownership, supportability, economics and a production release path. Exit requires deletion or transfer of data and assets, communication and closure of access.

Together, these gates form the preview charter. Approval belongs to the owners of the actual exposure, not one central innovation team acting alone.

Choose one of three outcomes

Explore is appropriate for synthetic, public or low-risk data with no business dependency. It answers product and interaction questions quickly.

Bounded Pilot permits controlled real work with named users, data, authority, duration, monitoring and fallback. It is appropriate when authentic conditions are necessary to answer the hypothesis and the consequences remain containable.

Do Not Deploy applies when data or action cannot be bounded, terms are unacceptable, a critical process would depend on uncertain continuity, or the organization cannot observe and reverse the experiment. The decision can be revisited when the product or operating environment changes.

A worked example: meeting follow-up preview

An operations function wants to pilot a preview that reads meeting material, creates follow-up tasks and drafts messages. The initial request is to give it to all managers.

The six gates reveal that drafting summaries is reversible, but task creation and outbound communication affect other people. Meeting content can include employee and customer information. The business has no fallback for automatically created commitments and has not reviewed usage-based cost.

The approved pilot includes twelve managers for six weeks. It allows meetings from two internal project teams, excludes HR and customer-confidential sessions, and permits draft creation only. A user must approve task creation, while external sending is disabled. Participants record correction effort, missed actions, inappropriate sources and time saved. The owner reviews consumption weekly. Every generated task is tagged so it can be found and removed.

The exit decision compares user value, error rate, control burden and current terms. Broader release requires a supported operating model and is not implied by pilot success.

Avoid two opposite errors

The first error is preview theatre: a large audience, vague purpose and no decision at the end. It creates excitement and support demand but little reusable evidence.

The second is applying full production assurance before a synthetic-data exploration. That eliminates the low-cost learning a preview is meant to provide. Match evidence to exposure, then increase it as data, authority and dependency grow.

Keep a portfolio record of previews, participants, owners, spend, review dates and graduation state. Watch for shadow production: recurring use, undocumented integrations, executive reports or customer communication built on a feature still described as experimental.

Amplified Pi designs previews as deliberate experiments. The outcome may be a production roadmap, a changed architecture or a confident decision to stop. All three create value when the learning is explicit and the exposure remains controlled.