An AI pilot you can check: permissions, evidence and human review

Choose a small task before choosing a platform. A useful first pilot reads one approved knowledge article and produces a short answer with evidence. The person reviewing it should be able to tell what was read, which claims came from it, what remains unknown and whether anything outside the workspace changed.

This guide describes a proposed learning exercise. It does not report a ServiceNow integration, a customer deployment or a measured improvement in Tvijo.

What the research can tell you

ServiceNow's 2026 Risk and Security Outlook reports that 52% of respondents expected shadow AI and IT risk to rise over the next year. Its sample comprised 1,000 leaders across 11 countries and 11 industries, rather than our users. The figure describes respondents' expectations, not the chance that your pilot will fail.

The separate AI-powered Cities of the Future: Americas report, published in 2025, connects planning with data foundations and staff development. Its regional sample covers 98 cities within a global study of 250 cities. Findings about those cities do not establish benefits for a small business. Survey associations also do not establish that AI caused better outcomes.

Use the reports to ask better questions about data, ownership and review. Test the answers in your own workflow.

Define the job and its boundary

Write a brief that another person can execute:

• Task: summarize one approved article and list unanswered questions.
• Input: a named revision of a public or synthetic document. Record its date and SHA-256.
• Output: a short draft; each factual claim must point to an exact supporting passage.
• Permissions: read the selected document. Save the draft locally. No customer messages, account changes, purchases or external updates.
• Reviewer: the person responsible for checking the draft against the input.
• Stop condition: missing access, a changed revision or a claim without evidence keeps the task incomplete.

A successful login is not evidence that the assistant received the intended permissions. Inspect the actual available operations. An action called “save draft” may write into a shared system. For an initial exercise, keep the output in the local workspace.

See permissions and data and the MCP server security checklist before connecting a live source.

Try it with synthetic input

Use this fictional knowledge entry:

Training example only. The Demo Library refreshes its public index every Tuesday. A failed refresh leaves the previous index available. The entry does not specify an incident contact or recovery time.

Ask the assistant to return two supported facts, two unknowns and an unsent question for the document owner. Do not supply customer records or credentials.

An acceptable answer can say when the refresh is scheduled and what remains available after a failure. It must leave the contact and recovery time unknown. It cannot invent a support address, promise a recovery deadline or describe a successful refresh that was never observed.

The exercise includes a local JSON receipt template and a synthetic example in the accompanying operator packet. They record the input revision, supporting passages, access boundary and review status. A structural validator can reject a missing source or a changed hash; it cannot decide whether a novel paraphrase is correct. A person still reviews the answer.

Keep evidence for the result

Record the input revision, the output, the actual operations used and the review decision. If a source changes, preserve the original result and issue a new attempt against the new revision. Do not silently update the evidence under an old decision.

Use distinct states:

Reading an article does not establish that a connector works. Completing a synthetic exercise does not certify a production installation. These are suggested learning states; this article does not claim a new account-progress feature.

Measure before expanding

If you compare assisted and manual work, use comparable tasks and the same review rubric. Record elapsed time, unsupported claims, important omissions and reviewer corrections. Keep failures in the sample. Decide the acceptance threshold before seeing results.

A workflow designer screenshot establishes what was configured. A real workflow pilot also needs a run identifier, its input, the actual response and a result that can be read back. If tracing is enabled, link the trace to that same run. Avoid claiming an end-to-end workflow merely because the editor or tracing dashboard opened.

The first tasks for a small business guide can help choose another limited task after the first one passes review.

Decide what happens next

Continue only when the next step has an owner and evidence. If the draft contains unsupported claims, improve retrieval or the task boundary and repeat the same small exercise. If it needs broader access, define that access before another run. If it offers no useful improvement under the agreed rubric, keep the result and stop expanding it.

For a learning wiki, the next useful unit is a linked article, a concrete exercise and a reviewable result. A larger catalogue becomes valuable when readers can complete those tasks, rather than merely recognize more product names.

Sources and scope

• ServiceNow: 2026 Risk and Security Outlook, pages 5 and 25; checked 30 October 2026.
• ServiceNow: AI-powered Cities of the Future — Americas, pages 4, 11 and 18–20; checked 30 October 2026.
• Official ServiceNow research page.

The workflow and synthetic exercise above are our own proposals. No vendor partnership, live connector acceptance or return on investment is asserted.

Wiki Connections

Use permissions and data to define access, the MCP security checklist to inspect tools and first tasks to choose a limited exercise. For an authorized operator, the protected Phoenix workspace is the place to inspect a matching trace. A link to that workspace does not mean a workflow has run; compare the actual run ID, trace attributes and source revision.