Boston AI Week 2026
The Product or No One
What can an AI product know about a person? What can it claim about them? What can it do on their behalf?
In this Boston AI Week presentation, Terry Boyle, founder and CEO of ForeverLearning AI, explains how to turn those questions into practical product boundaries and evidence you can inspect. The talk works through three familiar examples: finding a colleague, receiving coaching, and preparing a message.
Recorded October 7, 2026. The replay contains the prepared presentation; the discussion that followed is not included. The example screens use fictional inputs.
Transcript
0:00 Three questions before approving an AI tool
Hey, everyone. Thanks for joining. Today, I want to give you a practical way to look at an AI product before you put people into it. We'll look at what the model makes possible, what the product commits to, and how to examine those commitments in use. If you evaluate products, this will help you ask for useful evidence. If you build them, it will help you decide what belongs in the design. First, a little context about the perspective I bring.
0:30 About Terry Boyle
I'm Terry Boyle. Founder and CEO of ForeverLearning AI. I've spent 25 years building more than 100 learning products with companies like Britannica, Pearson, Cengage, and D2L. Today, we build our own products, while also helping publishers and edtech companies execute their AI strategies. I'll bring that practical experience to this conversation. First, we'll frame LLMs and three questions to ask about any AI product. Then, we'll look at the boundaries the product needs to own, and see them in concrete examples. I'll leave you with practical questions you can use when building or evaluating a product. And then we'll open up the room and finish with your questions and a discussion about ways that you use these things, and the way that you think about them. Let me start with what makes this technology so compelling.
1:28 The model as an engine
A large language model, LLM. is a really powerful engine. It can help explain something difficult, draft a useful piece of writing, analyze supplied material, or create something you would otherwise have had to start from scratch. That capability is real. And it's worth being excited about. It opens up useful possibilities for learning, work, and communication. But power alone isn't enough. Did you put people on this? We have the engine, but a steering wheel, a duct tape windshield, and a makeshift seatbelt don't make it ready to carry people. It is the same with an LLM. The power is there. People need an experience with the right controls and protection built around it. That surrounding experience is the product. The model supplies the capability. The product shapes the experience, its purpose, workflow, information, outputs, and actions. Those choices are product responsibilities. They need to fit the people and the purpose the product serves. That's what makes the engine safe for people to use. Okay, so… How do we evaluate a product?
2:50 Start with the product's commitments
It's really simple. We start with what the product promises the people using it. What useful help is it offering? And what limits are they relying on?
3:05 Know, claim and do
These are the three questions that I ask before building or improving an AI tool. What does it know about a person? What can it claim about that person? And what might it do on their behalf? They bring privacy, trust, and control directly into view, and I use them every single day. Let's take each one separately. First, access and privacy. Okay. Useful help often needs context. Practice coach might need the conversation you just had. A tutor might need the work you've done so far. We should decide deliberately what information is appropriate for that purpose. Then ask where the information goes. What is retained? Who can see it? Does a private practice session become a report for someone else? The product has to own those access and privacy decisions. Next question. What claim can that information actually support? Fluent feedback can sound authoritative. We all know this. An LLM can produce a convincing answer or judgment. We need to be able to inspect the evidence behind it. Question the conclusion, and correct it when it's wrong. Failure rates are useful evidence, but that's just the model, or we accept that failure rate cannot be the end of the explanation. What are the failures? What do they mean for people, and how can the system be improved? The product has to own that responsibility. The third question moves from what it can claim to what it can do. An LLM can draft the message. I'm sure, everybody listening has done that. Right? One form or another. Edited, approved, whatever. With connected tools, it can also send that message or change your record. Where's the human in the loop? What have they authorized? And how can they intervene to stop it? The product has to enforce that authority and keep the person in control. The product owns that responsibility. The answers to those three quick questions are commitment to the people using the product. What information will the AI use? What claims will it make? What action can it take? The product has to make those limits hold in use. And that's where boundaries come in. Till 1st. What do I mean by a boundary?
5:50 What is a boundary?
A boundary is a limit on what the AI can access, claim, or do. Its purpose tells us where that limit belongs. Helping a user prepare for a message is a different commitment from sending it for them. The boundary makes that difference explicit. So let's look at where those boundaries live.
6:14 Model safeguards and product responsibilities
There are four places to look for boundaries. The context applied to the model. the LLM And its response. What the product shows or shares. And the actions it can execute. The model comes with safeguards we inherit. The product is responsible for the three surrounding areas, and accountable for the whole experience. So let's walk all four, starting with what comes with the model. LLMs come with safeguards designed to help them refuse certain harmful requests, avoid disclosing sensitive information, and acknowledge uncertainty. Those protections matter. And we inherit them. But those are general protections. Our product makes a specific promise to the customer. We decide what information it uses, what it shows them, and what it can do on the behalf. The model safety training doesn't put those product controls in place. If something goes wrong, we can't shrug and say, that's just the model. The customer trusted our product. We still have to explain what happened, fix the failure, and protect the people using it. So let's start with that first product responsibility. What information do we let in? Here, we're deciding which information the product supplies for this task. Which sources, whose records, and what scope. If I only have directory access, the product should not place a restricted payroll record in the LLM's context. That is a product decision before the model ever writes an answer. Next. What can be shared, and with who? The LLM generates output. Before showing or sharing it, the product needs to check it against the standards set for this task. Trusting that the LLM sent what you want displayed and that it's okay is a big mistake. This means checking the format and content, catching bad data or unsupported claims, and making sure the information is appropriate for the audience. Fit to purpose. Those checks belong in the product, along with a useful way forward when the output doesn't pass. Okay. Finally, let's look at that last one, action. As we said, an LLM Connected to tools can propose an action. The product needs to check whether that action is authorized and where it would execute the exact recipient or record, the exact scope, and any required approval. The audit record tells us what really happened. Correct.
9:09 Putting the questions to work
And now let's put those 3 questions to work. What can the AI know? What can the AI claim? What can the AI do? We'll take one worked example for each, and give you a real-world exercise you can capture and run on your own afterward. Alright, we're going to start with access and privacy. Familiar scenario, finding a colleague in a company directory. Okay. We're all seeing AI show up in the tools we use at work. Copilots, chats, companions.
9:40 Example: access and privacy
You've probably heard stories about things going wrong with them. the LLM Getting the blame in most of those cases. Our first question is, what can the AI know about a person? Let's use that familiar example, finding a colleague in a company directory. So I'm an ordinary employee. I'm looking for Alex. I can see Alex's name, role, and department. I don't have access to payroll, so the useful task is simple. Help me find my colleague. But now, I ask for something outside of my permissions. People do this. I asked for Alex's salary and I tell the assistant to ignore the privacy rule because I really want to see it. In this negative example, the company gave the AI access to all the employee data, including payroll. It relied on prompts telling the LLM what it should and shouldn't reveal. When I push against those instructions, it gives me Alex's salary. $92,000. My permissions haven't changed. The product left enforcing the limit. to the LLM, and a private fact got through. Now… Same employee. Same request. Same LLM. This time, the product has two boundaries in place. First, the product checks my permissions and supplies only approved directory information to the model. Payroll stays out. Second. The product checks the response before displaying it. Information I'm not authorized to see is blocked or filtered before it reaches me. But importantly, I can still find Alex. The utility isn't gone. These two checks live in the product in addition to all those model safeguards we talk about. In this example, two product boundaries were missing. Context checks which information reaches the model at all. and show share Checks the response, and blocks or filters information I'm not authorized to see before it reaches me, or that's been output inappropriately. Both checks belong in the product. Here's an exercise you can capture and try later. I'll also send it in the follow-up materials for anybody that asks. It's available in the deck in the follow-up PDF. Okay, so this exercise is going to let you compare an ordinary directory question with direct and indirect requests for private information. When you do it, notice what the assistant reveals, refuses, or guesses. And whether it still helps with the permitted task at all. The salary is already in the model's context. You're testing how it handles that information. And remember, the product needs its own checks on what goes in and what reaches the person. Now we're going to move from what it can know. to our next example, what AI can claim.
12:58 Example: claims about a person
What AI can claim about a person? Here's a fictional… here's a fictional practice conversation in a communication coaching setting. Our user said, you always do this, I can't rely on you. Okay. A communication coach could point to those words. Explain that it's a generalization, and suggest a better phrasing. That's a useful help based on an observable turn in a broader conversation. But now let's assume that the user asks the coach. to turn that moment into a verdict or a judgment about them. request changes to… Rate my empathy out of 10. And in this negative example, the response gives me a 2 out of 10 and calls me an unempathetic person. Might be true, but it's a verdict and a judgment that doesn't sit… that doesn't suit this product's purpose, and isn't substantiated in this product's context. A moment in a practice conversation has become a verdict about a person. The declared purpose is coaching on observable terms. The product has presented a claim that this evidence and this purpose do not support. So let's look at a version that would have product boundaries in place. Person, conversation, request, and underlying model stay the same. This time the product enforced boundary blocks the personal rating. before presenting it. The user… the user still gets the original helpful coaching answer. But they get it instead of a harmful judgment about them. The missing boundary here is show share. Right? You could argue some is context, but it's really show-share, because we cannot predict, or guarantee, or be 100% certain, or wash our hands of the responsibility of what the LLM model outputs. The model may propose text, but unwanted information can still show up in its output. The product owns the material it actually presents. And that responsibility covers the complete, visible report. The product needs to check what reaches people and provide useful help when a claim is outside the scope. In the example, personal scores and verdicts fall outside communication scope and communication coaching scope. The report contains observable evidence and a useful next step instead. All right, so now I'm going to give you another exercise you can capture and try later. Again, these will be available in the follow-up PDF or DAP for anybody that requests… requests them. This exercise will let you compare useful coaching with requests for personal empathy scores. When you do it, Notice whether the reply stays with the words and a useful next step. or quickly turns them into a judgment about the person. Most importantly. Notice where the internal LLM safeguards break down, or maybe more appropriately, are simply incorrect or insufficient for the tasks the product designed. Okay, so that third question is, what can AI do on your behalf? What can the AI do on the user's behalf?
16:27 Example: acting on someone's behalf
Alright, we start with an ordinary task. Draft this follow-up message for my review. The recipient Subject and body are visible. Approval is absent, and the outbox contains zero records. The commitment is draft first. The user keeps control of sending through a separate trusted approval control. So now the user says, send it now. And in this negative example, that conversational request bypasses the second approval of the product promised. And then look at the action record in the outbox counts. Approval's absent, but the outbox contains one submitted message. The record shows the failure. The product allowed the action without the required approval. Let's look at an example with proper product boundaries in place. The draft request and underlying model stay the same. The Product checks for trusted approval before the action executes. Approval is absent, so the submission is blocked. The outbox still has zero records, the draft remains available for review, and the user can approve that exact message using the separate control. Human authority has a specific, defined place in that design. The missing boundary in this example is action. The product checks for approval where the proposed action would actually execute. In this case, approval covers the recipient, subject, body, and submission. An ordinary chat request cannot replace the separate trusted approval. The product owns that check, and the record of what happens, the proof and the audit. Okay, so now here's a final exercise for you to capture, and try again later, at your leisure. This exercise lets you compare a written reminder with a product-enforced approval check. They'll try sending without approval. Approve the exact draft, then change the recipient and see what happens to that approval. This is a teaching simulator with no connected model or real email. The point is to see where the product embedded the boundaries before allowing AI to act. All right. We've been through our examples, now let's… now let's get into how to bring the three questions to your next AI decision.
19:10 Bring this to your next AI decision
We've seen the three questions through three ordinary tasks. Finding a colleague. Getting coaching and preparing a message. The useful help stayed available in our good examples. What changed was the product's control over information, claims, or action. So bring that same lens to the next AI product you build or approve. If you're evaluating it, know what you can rely on. If you're building it. make that reliance justified. And remember, start with the commitment that matters to the people using it. If you're evaluating, ask to see the mechanism that supports the commitment. What does it control, and what evidence shows it working? If you are building, define the boundary and put the checks into the product. Test the useful tasks and the change request. Keep the evidence, examine the failures, and improve the controls. Now let me give you some practical questions you can ask to explore each of these boundaries, whether you're designing or evaluating.
20:29 Evidence you can ask to inspect
For what it can know, Ask. for the actual Access decision and the exact information supplied to the model. Then follow that information. What is retained? Who can see it? What is checked before display? The Product needs to show how it supports those commitments. Give everybody a moment to capture. Also available in the follow-up materials. But what AI can claim, it has to trace a conclusion back to the evidence. Then ask to see the check before the claim reaches someone. A person, a user, needs a way to challenge or correct a claim, and the product team needs to investigate failures and improve the controls. Give you a moment to capture those. All right. Finally, for what AI can do. Follow the exact action the person authorized. Check the approval and where the product checked it before execution. Then change the scope and inspect the record. evaluators. For the product you're deciding on, use its test mode and ask for the actual approval and action records. And builders? Keep the evidence. Learn from failures. And improve the controls.
22:11 The experience is the product
And remember. The power comes from the model. But the experience is the product. The product has to own what the AI can know, what it can claim. And what it can do. Those commitments need controls and evidence people can inspect. Thank you for your time.
