AI Comes to Business: What Changes When Any Department Can Ask Its Data Questions
By Sebastián Grattarola — CTO of BigCheese, a Premier AWS Partner
In almost every organization, there’s a recurring scenario. Someone in sales needs to prepare for a meeting with a client and wants to know what was delivered on the last project. Operations wants to know which projects are behind schedule. Someone in management wants to see a metric without waiting for the end of the month. And in all three cases, the response is the same: ask someone else, and wait.
The bottleneck isn’t a lack of data. The data exists: it’s in emails, in shared documents, in management systems, and in the data lake. The bottleneck is availability and access. The information is there, but accessing it requires knowing where to look, having permissions for five different systems, or relying on someone from the data department to put together the report.
Generative AI can solve that, but only if it reaches the people who make decisions every day—not just the technical teams that build it. That’s what this article is about: what changes when a business can ask its data directly, and how we’re seeing this in practice with Amazon Quick, both at BigCheese and with our clients.
From requesting a report to asking a question
The fundamental change isn’t technological—it’s a change in habits. For years, the way to get information was to request a report: someone specifies it, someone builds it, someone reviews it, and days later a response arrives that often raises a new question. We request and build dashboards: dozens, hundreds, thousands of them. They contain repetitive information and always lead to yet another question (and yet another dashboard). With an AI assistant connected to the company’s data, that chain is reduced to a single question in natural language and an answer that explains where the information came from.
That last point is important. An answer without a source is just an opinion; an answer that cites the document, email, or dataset it came from is something that can be acted upon. That’s why the value isn’t in “having a chat,” but in the assistant working with the organization’s actual sources (the spaces containing each department’s documentation, email and calendar, and the existing dashboards and datasets) and always respecting what each person is authorized to see.
Use cases we see in non-technical departments
The cases that generate the most value are rarely the most sophisticated ones. They are the ones that resolve an everyday friction that no one had been able to address because it didn’t justify a custom solution.
Project closure and deliverables.
In a service company, what is delivered to a client is scattered across the project team members’ email inboxes, personal folders, and the project’s “official” repository. When closing a project, reconstructing what was delivered is a manual task prone to omissions. Today, the project manager and the technical lead ask the assistant to search their email for deliverables sent to the client as part of the project and compare them with what’s in the official folder. The result is a list of missing items to be completed. What used to take an afternoon of searching has become a standard query, and we’ve defined it as a standard prompt so that all PMs follow the same process.
Project status without status meetings.
With a space that brings together project documentation, email, the calendar, and notes from the last daily stand-up, anyone in management can ask what came out of the last meeting or how a milestone is progressing—and receive a response with the relevant references. The project team validates the response rather than drafting a report from scratch.
Operational tracking.
The detection of unrecorded hours—which previously required manually cross-checking export files—is now handled by an agent that reads data from the data lake and notifies the appropriate person. The operations department no longer has to track timesheets and can focus on exceptions.
Implementation at a financial institution.
At a bank in the region, following a demonstration of specific use cases involving its own processes, the client’s internal AI team took the lead and defined a phased rollout by business area (operations, human resources, administration, contact center, executives and advisors, and so on). Our collaboration was organized along two fronts: business use cases on one hand, and platform administration and governance on the other. In a regulated industry, it is this second front that enables the first (and is absolutely essential!).
Not everything is handled by the assistant
One lesson we learned quickly: not all use cases need to be handled by the assistant. When the value lies in a person asking questions, exploring options, and making decisions (researching, summarizing, comparing, preparing), an assistant like Amazon Quick is the right tool. When the use case involves an automated process—with integrations to transactional systems, strict business rules, and high volume—it’s best to build a custom agent on Amazon Bedrock AgentCore.
Having that clear criteria from the start prevents two common mistakes: forcing a process into the wizard that requires robust integration, or building a custom solution for something the business could have resolved on its own in just an afternoon. This type of definition is what comes out of the AI Assessments I mentioned in another post.
Adopting Technology Without Losing Control
Bringing AI into the business doesn’t mean opening everything up. Adoption works when the assistant enters through the same door as the rest of the tools: corporate identity, spaces organized by department, and permissions derived from existing groups. This way, each person sees only what they were already able to see, and the security team governs the AI using the same model it uses to govern everything else. We explore this approach in detail in “Govern AI Before Scaling It.”
How to Get Started
What we’ve seen work is the same approach we recommend for any AI initiative: think big and start with something achievable.
- One area and a few use cases, with clear value. Better to have three use cases that people use every day than twenty that no one remembers. For the clients who got off to the best start, the rollout began with a limited group of users and expanded based on what those early users achieved.
- Training designed for non-technical departments. The tool won’t catch on on its own. A short list of sessions tailored to each department, featuring real-world examples from that department, is more effective than generic training. It’s also a good idea to identify champions who will promote its use within each team.
- Measure usage and value. How many people use it, what they use it for, and how much time they save. This is the basis for deciding whether to scale, and it ties directly into the logic of building a business case before investing.
- Standardize what works. When a use case demonstrates value, it becomes a prompt, a shared space, or a shared agent, so it doesn’t depend on who discovered it.
The Point
AI generates more value when it’s used by decision-makers, not just by those who build it. Technical teams will continue to build agents and platforms, but the biggest leap in productivity comes when sales, operations, and management can answer their own questions—using the same sources and controls as always—without relying on the developers (or having to build them themselves!).
The challenge isn’t the technology—it’s shifting from the habit of asking for things to the habit of asking questions.
Sebastián Grattarola
CTO at BigCheese, an AWS Premier Partner. I help fintechs, retailers, and payment companies in Latin America build on AWS with governance, security, and scalability.