What an AI Should Not Be Allowed to Do in Your Project Tool
The demo will show you what the AI can do. It will not show you what happens on a Tuesday night when nobody's watching. Those are different questions, and only one of them matters once you've signed.
Every vendor demo now has a slide where the AI does something impressive while nobody touches the keyboard. It reschedules a task. It drafts a message. It closes out a checklist. The room nods. Nobody asks the only question that matters for a client-facing team: what happens when that same AI is wrong, and nobody happens to be looking at the screen when it acts?
You are not buying a feature. You are buying a new actor in your workspace — one that can, in theory, touch a client-facing deliverable at 11pm on a Thursday while you're asleep and your client is awake. The question isn't whether the tool has AI. Everything has AI now. The question is what it's permitted to do when you're not in the room, and what you can see afterward if it did something you didn't expect.
The permission question most buyers forget to ask
Ask the vendor this directly: does the AI act on its own permission level, or on the permission level of the person who asked it to do something? These sound similar. They are not. An AI with its own elevated access is a second admin account that nobody remembers granting. An AI that can only do what the asking person could already do, through the same actions the buttons already use, is a tool wearing a different interface — not a new source of risk.
In Team and Tricks, TAI runs as the person using it. It uses the same actions the buttons in the product use. A member asking TAI to do something only an admin can do gets the same refusal they'd get from clicking the button themselves. There is no separate AI permission matrix sitting behind the one your team already understands. That's not a marketing flourish — it's the difference between an assistant and a backdoor, and it's worth making the vendor say it in plain words rather than inferring it from a feature list.
Does it act, or does it propose and wait?
This is the one to spend the most time on, because it's where vendors get vague on purpose. "Automates" and "handles it for you" sound identical in a pitch deck whether the system executes immediately or stops and waits for a human. Ask for the literal sequence: what does the screen show, and what does a person have to physically do before anything changes?
A workable answer sounds like this: the AI prepares the change — a filled-in form, a scheduled date, a reassigned owner — and shows it to the person before anything happens. The person can edit the wrong field directly on that form, not file a correction afterward. Then they press something that means apply, or they press something that means stop. If the vendor can't name those two states, or if "stop" turns out to only pause automation that's already running, keep asking.
TAI prepares a single change at a time and shows it as a filled-in form before anything applies. The person presses Apply change to confirm it, or Stop, and nothing happens until they do. If something's wrong — the wrong date, the wrong assignee — it gets fixed on the form before confirmation, not cleaned up after the fact. That ordering is the entire trust model. Everything else is detail.
Can approval be switched off, and by whom?
Some tools let an admin disable the confirmation step entirely, usually framed as a power-user setting for "teams who trust the AI." This is worth asking about specifically, because it's the setting that turns a safe default into an unsafe one with a single toggle, often flipped by someone optimizing for speed on a bad day.
Ask whether the apply-and-confirm step can be bypassed for any user, any role, or any task type. Ask whether a client-visible deliverable can be set up to skip it. If the answer is yes, ask who decided that was acceptable and whether it was documented anywhere other than a settings screen nobody audits. A tool that can be configured out of its own safety behavior hasn't really shipped that behavior — it's shipped an option.
What triggers it to act without being asked
The more interesting unsupervised question isn't about a single command — it's about standing behavior. Does the AI do anything on its own initiative, without a person opening a chat and asking? If so, what exactly triggers it, and is that list fixed or does the vendor describe it in vague terms like "when it notices something needs attention"?
Vague triggers are the tell. "Notices stale work" or "flags things that need attention" sounds helpful until you ask what counts as stale, who decided, and whether it will someday flag something you didn't want flagged to a client's guest account. A narrow, named list is a better sign than a broad, impressive-sounding one. TAI follows up on its own in three specific situations: a deadline is close, a deadline has passed, or a task has been sitting as a draft rather than launched. That's the complete list. It doesn't scan for general staleness or make judgment calls about what looks neglected — because that kind of open-ended judgment is exactly the thing you don't want running unattended on a client account.
What does the record show afterward
Ask what happens after the fact. If the AI prepared a change and a person approved it, is there a trail showing who confirmed what, and when? This matters less for catching the AI in a mistake — the confirm step should have caught that — and more for catching the human in a rushed approval. "I didn't really read it, I just clicked apply" is a known failure mode for any approval gate, software or paper. A tool that makes the prepared change genuinely visible and editable before confirmation reduces how often that happens. A tool that buries the change behind a one-line summary and a big green button invites it.
Ask to see the actual form the AI produces before you buy. Not a screenshot in a deck — the real thing, with a plausible task filled in. If it reads like a summary of what will happen, that's weaker than if it reads like the thing itself: the due date field, the assignee field, the title, editable in place. The difference tells you whether confirmation is a real checkpoint or a formality.
Why this matters more for you than for the vendor's other customers
You're not the only stakeholder in this decision. Your client is a silent second party to every permission question above, even though they're not in the sales call. If an AI edits a client-visible deliverable overnight and gets it slightly wrong, you're the one who has to explain it in the morning — not the vendor, and not the person on your team who clicked something three days ago without reading it closely. The cost of a permissive AI doesn't land on the person who configured it. It lands on whoever's name is on the client relationship.
That's the real reason to ask these questions before you sign, not after. A tool that can't answer "what is it permitted to do when nobody's watching" in one clear sentence is asking you to find out by experiment, on live client work, after the invoice is paid.
The checklist to bring into the call
- Does the AI run on the asking user's permission level, or does it have separate, elevated access of its own?
- Does it act immediately, or does it prepare a change and wait for a person to confirm it?
- Can the prepared change be edited before confirmation, or only corrected afterward?
- Can the confirmation step be switched off for any role or task type, and by whom?
- What is the complete, specific list of things that make it act without being asked — not a general description, an actual list?
- What can you see afterward that shows who confirmed what, and when?
None of these questions are about how smart the AI is. They're about where the authority sits and when a human gets to see the work before it becomes real. That's a smaller question than "does it have AI," and it's the one worth your time in the demo.
