Hello, everyone. Thanks for joining in. Today's session for the roundtable is AI-Ready Workflows Demand Quality Data: Building the Foundation. Today, we are going to spend most of our time talking about the part that tends to be a little bit less glamorous than AI itself, what actually has to be true underneath it, right? Before we begin talking about the AI workflows, it's worth recognizing where most organizations are today. Most teams are not beginning with autonomous workflows. They're probably using APIs, connectors, Workiva chains, Workiva scripts, tables, Workiva approvals to do their ETL workflows, validate their data, and publish their data. As a user of Workiva platform, and AI expands across finance, ESG, GRC, these workflows often become more interconnected and more business critical. That work is not separate from the AI journey that most organizations are embarking upon.
It is actually the foundation of it, right? An AI agent or tool can only operate effectively when it has reliable context, it has approved tools, appropriate permissions, business rules, and an escalation path. Many of those components required to establish that environment actually already exist within organizations' Workiva implementations. The question, therefore, is not simply how quickly can we introduce an AI agent. Probably the more useful question is, what must be true about our data, about our workflows, and governance before we can safely allow AI to use these capabilities? Today, we want to explore that question through the practical experiences of our partners. With that said, please, I want to give a quick welcome to Steven Schwarz, Tony Scalese, and Brandon Rubin. Thank you all for joining in.
I would love for all of you to give a quick introduction of yourself and the organization that you belong to. Steven?
That's great. Appreciate it, Ankit. Thank you everyone for the opportunity to be part of this panel today. I'm Steven Schwarz. I'm a Partner with Alpha FMC. We are a boutique consulting firm that specializes in the financial services industry and have been a Workiva partner for a little over eight years now. So very excited to be here to share about our journey and experiences, and the particular nuances around data and AI as it relates to our financial services clients. Thank you, Ankit.
Tony?
Morning, good afternoon, good evening. I echo what Steven had to say there in terms of thanking you for being able to participate in the panel again. We had a good time doing this in Amplify, so it's nice to run it back. I am a founder of Bespoke Data Management Consulting Partners, or just Bespoke. We focus on financial reporting and the integration and automation around those key reports and key sets of data. This is a topic that's near and dear to my heart, and I am looking forward to the conversation today.
Last but not least, Brandon.
Thanks, Ankit. Thank you everybody for spending some time with us here today. My name is Brandon Rubin. I am a Director with RSM US. We are one of the largest global audit, tax, and consulting firms, and I personally sit within our data and digital services team, where I lead our Workiva practice. I have done that for the last five years, but have been with the firm for a little bit over 11 years in a number of different technology and transformation roles. Spend a lot of time with our clients today, working with them on how they can improve their usage of Workiva through in-platform and platform-adjacent AI solutions.
Thank you. Thank you all for the introduction. For everyone joining in, if you have any questions during the webcast, you can submit them through the Q&A engagement tool. We will try to answer these questions during the webcast, but if a fuller answer is needed or if we run out of time, it will be answered later via an email. Please know we do capture all the questions that you are submitting to us. For those who are looking to receive CPE credit today, please note we will be asking you to answer four multiple-choice questions during today's event. Receiving your credit is dependent on submitting an answer for at least three of those questions and attending the full duration of the webcast. If you are watching it as a group, please log in individually so you make sure you receive your credit.
These questions will pop up in the middle of your screen, and there will be a limited amount of time for the answer to be submitted, so please make sure you are ready to answer those questions when they appear. Lastly, please do not make sure your media player is full screen, as this will cause you to miss the pop-up questions. Once you have met your CPE requirements, your certificate will be available for download in the CPE certificate engagement tool on your screen and in an post-event email, which is sent about an hour after the event. Unfortunately, we are unable to provide any CPE credit to those who have any technology issues that is preventing them from qualifying or who miss the polling questions. Okay. Today, I want to structure our conversation around four areas.
We will start with what many of you are already dealing with today, what happens as automation scales, what continues to work, but equally importantly, where it starts to become brittle. From there, we will move underneath those workflows itself and talk about the foundations of data. Before we introduce more intelligence into these workflows, what needs to be true about the quality, structure, governance, and the accessibility of the underlying data? Once that foundation is there, we will move into AI-ready workflows where we would explore where AI should actually participate, where traditional deterministic automation still belongs, how we think about orchestration, human in the loop, and discuss emerging technologies or capabilities like MCP that allows AI to interact more directly with platform context and actions.
Finally, we will talk about the operating model, because none of this really scales unless there is clarity around who owns it, how it is governed, and how it is monitored, and how it evolves over time. Before we get into the webcast experience, two numbers to set the stakes. Gartner says 40% of enterprise applications will carry task-specific AI agents by the end of this year. Same firm also says over 40% of agentic AI projects will be canceled by 2027. Reasons might be cost overruns, unclear value, risk controls. Both of those numbers are true at the same time, right? That gap is what this whole session is about, and the data foundation closes that gap. Here is the first question as part of the CPE credit. Where is your organization today with AI in its Workiva-related workflows? Options are still exploring, piloting, actively scaling, already in production.
I will give it a few seconds. Let us start with the reality most enterprise teams already know. Something can be a successful automation and still become fragile as more people, processes, and system depend on it. I want to look at it from both sides. What continues to scale and what starts to break? Steven, we will kick it off with you. Alpha works heavily with investment fund organizations and investment management companies where you can have complex processes, multiple data sources, and a lot of regulatory reporting. When you see an automation that works really well for one process begin to expand across an enterprise, what tends to change? Then just a follow-up to that is what separates something that scales cleanly from something that eventually starts to become difficult to maintain?
Yeah, that's a great question. The nuances of the private equity space, the real asset space particularly, definitely we've seen a lot of this with our clients as we look to scale to hundreds and thousands of different financial statements inside of the Workiva platform. There's a key difference between something that is automated and something that's actually designed to scale. If you think about starting with something small, you can probably tolerate a couple of manual steps. You can tolerate uses of spreadsheets or embedded calculations, hard numbers embedded inside of calculations, exceptions, et cetera. That could all live inside of people's heads. At a small scale, maybe 10 reports, et cetera, that's something that's manageable.
You can build processes that exist around it, and that makes it better, and you have the great power of Workiva, but it's still not fully scalable, still not fully automated. As you look to scale, what often happens is those dependencies begin to multiply. As you start to look at different fund structures, different source systems, exceptions in those calculations, different parameters and different elements of that data, that's when it starts to fall apart. Then you start to basically building this cottage industry to handle all those exceptions around your automation process, and you no longer have this ability to scale. When you think about what separates our clients' ability to scale successfully inside of a tool like Workiva, it's establishing the architecture, so common data, building your reporting data mart, so essentially having that foundational layer established and documented.
We'll talk more about kind of some of the nuances around how you can codify some information there later today. Also the standardization, right? What are the common definitions? What are the common narratives to calculations? How do we establish templates that actually handle not just the first 10, but also handle the last 100, the last 1,000? Then the most important part, obviously, the ownership and governance around it. Who owns that architecture as it expands? Who's accountable for maintaining those integrations and enforcing the standardization of those templates? So that's really been something that we've been working a lot with our clients. Then obviously, as we have this increase in AI, you're potentially creating risks of having 50 disconnected agents, different reports, and you're kind of band-aiding these processes together.
That's really where I think the power of that scalability and a platform like Workiva becomes so powerful as you look at that kind of AI operating system where you have shared memory, shared integration, and shared business logic, all codified and memorialized inside of the Workiva platform.
Great. You did touch upon a topic of ownership that we're going to talk at the end of the session as well, but thank you for bringing that up. Tony, you get to see this across a broad range of data management implementations. Now, when you inherit an automation that has evolved over several years, what are the warning signs that folks can see or that tell you it has started to become brittle? Any thoughts on that?
Yeah, there's definitely a few things that start to surface every time something has become brittle. One of the big things that I see is performance, right? Steven kind of alluded to this in what he was saying in that, okay, we got it working for the first 10, maybe the next 100, maybe the next 1,000. Those little incremental things that the performance was a little slow on it, we have got a couple extra steps in the process, those really don't hurt us until we really start to scale. I think that that's one of the areas that I see most is that starts to happen, it starts to be brittle. The other thing I start to see is that somebody doesn't actually know how to describe what the process is doing and why it's doing it. Maybe they've inherited it.
This goes back to something that we're going to talk about over the course of the conversation today, is this idea of giving context to things. Part of context is documentation, right? It's one of those things that nobody likes building documentation, but it is becoming more and more critical for us to inform and give information to AI and to our processes so that they continue to scale with us, and you don't create a key person dependency. Those are two big things that I think of right off the bat, but there's obviously a number of things that can happen.
Thank you. Now, Brandon, you work a lot in GRC and audit space, where automation is important, but also traceability and control, right? It's as important as automation in there. Now, does the definition of brittleness change when you are in GRC and audit space, from your perspective?
I don't know so much that it changes, but it certainly, I think, gets a little bit more complex when we think about from an auditor control standpoint. We have to think about where are those folks embedding AI within the work that they're doing on a day-to-day basis, and then what's probably a lot scarier is where the work that they're auditing is embedding AI, right? I think when we look at where, let's say, an internal audit team is using it for a particularly targeted use case or maybe for some manner of predictive analytics, you can kind of maintain it in a way that is going to allow you to do it in a more targeted manner versus necessarily having to go enterprise-wide and maybe build something that's going to be more brittle.
But when we look at the work that those folks are auditing, I think that's where there's a lot of risk introduced when people are starting to deploy AI, even in very small ways in their own kind of little fiefdoms. That's really where there's a lot more risk introduced in how frequently these processes are changing, and where people might just be filling gaps in processes with AI without kind of the, as Tony mentioned, the thorough documentation around what does it look like, what are the results that it produced, can it be repeated. I think that's where we see in the risk and audit space, just a lot more risk introduced, and a lot more potential for more fragile processes.
Absolutely. Yeah, just from the discussion, right, it's the definition of scale itself. Scale is not just throughput. It's whether other people can understand it, they can operate it, they understand the context around it, can they change it, can they actually trust the scalability of an automation. Now, that discussion takes us to what's underneath the workflow itself. Now, before we get to that's question number two. What is the biggest obstacle to making your data ready for AI? Is it inconsistent data quality or structure, missing business context or common definitions, access and governance controls, or no visibility into when inputs change?
Now, Tony, I want to start this section with something that you had raised during some of our discussions before. You made the point that particularly in financial, quantitative, governance-related use cases, structured data is not an optional thing, right? Especially if you expect AI to move beyond those isolated experiments. So the question is, can an organization be AI-ready if its underlying data architecture is not automation-ready?
Want the standard consulting answer? I mean, look, it would be tongue in cheek to say yes or no here. I do think that there are certain AI available things that you can do in an organization that maybe don't rely on your data being structured, right? If there are things that allow you, and I'm racking my brain to think about what those might be, but you can absolutely have AI being used in the organization, right? For example, commentary. That's highly unstructured.
Right.
Well, if you look at some of the things that Workiva's working on, and I'm sure Workiva's going to talk about it here in the coming couple of months, commentary is such an important thing as we're trying to understand what's happening in the business. It's hard to put structure around that. How people type their explanations, you can certainly use AI for that.
Absolutely.
Use that to be able to help you see the needle in the haystack, to get the theme of what's being said across multiple different business units. But if we're talking about data and things that you really need data, financial numbers, I don't think you want to layer AI on top of something that doesn't have good structure and good architecture around it. Because, I remember when we were talking about this during Amplify, we talked a lot about deterministic.
Right.
A lot of what happens with financial reporting and even GRC to some degree requires deterministic outcomes. If your data's not structured, you're less likely to get a deterministic outcome, meaning it arrives at the same answer every single time.
Yeah.
Right? Without structured data, you are putting that at risk. The answer is, it depends, and hopefully that context helped everybody think about it in the different ways.
Absolutely. Steven, I will take that question again into the investments fund environment, right? Where you can have a very sophisticated organization, you can have a sophisticated process, but you can also still have the information arriving from multitude of systems, right? It can be manual typing of data from different teams. It can come from other external systems. In that context, what does trusted data actually mean in that environment? The follow-up is, what do customers need to actually standardize before they can realistically scale AI-enabled workflows?
That is a great question. It is something that we have been talking to our clients about for, it feels like eternity, but especially this last year as we kind of worked through this. I think folks have been on this journey around data, around setting up their enterprise data warehouses for at least a decade. But I think what we are starting to realize is what AI has brought to light is the importance of that trusted data, right? It is not good to just set up your medallion layer and have validated data products that are available. What is missing to make AI really powerful and AI trusted is the codification of the knowledge, right?
If you think about investment management space, right, there is no lack of data, right? There is plenty of data. You have portfolio data, you have fund admins giving you data, you have your general ledgers, your ABOR, your IBOR. There is so much information. But what is missing is the definitions, the authoritative sources, the lineage, and the business context. That is where we are spending a lot of our time right now with our clients. If you think about a simple example, right, AUM. What does asset under management mean for a client? It can mean something different between clients and even within the same organization, depending on which team you are talking about.
Is it NAV? Is it committed capital? Is it invested capital? Is it fee-paying AUM? I mean, these are common challenges that we are struggling with. And where all that knowledge exists is in the minds of all the employees. So, all those folks that have been in these organizations for years and decades, it all sits in their brains. The biggest challenge that we're having to build trusted data right now is extracting all that information and codifying that into the semantic layer. That's really a powerful aspect, and what helps really accelerate the power of Workiva is when you define that information and codify that information inside a Workiva platform. It becomes immensely powerful when coupled with tools like MCP, which we'll talk about later. Yeah.
Okay. You mentioned you've been working with a lot of organizations to codify that data. Do you feel the organizations underestimate the importance of context?
They are. I think that's one of the biggest gaps that we're seeing right now is folks feel worried potentially that their jobs are at risk because they're sharing the keys to the kingdom or that secret sauce that they have held onto for so many years.
Yeah.
Really, that's the key to the unlock, is when you're able to extract that information, you get out of production, you get out of report production, you get out of data creation, manipulation, you get out of those Excel files, because you can now turn it over to these AI tools to add a tremendous amount of value to your organization, because they have the same information that you have. So, when you ask a question, you get back an Excel model or a HTML dashboard, or tied into your broader reporting process within Workiva, you're getting the right answer.
Yeah. Okay. Before I go back to Tony again, this is the third question. Where would you be most comfortable allowing AI to act in a production workflow today? Summarizing or classifying information, flagging exceptions for human review, recommending actions for a human to approve, executing actions autonomously? Back to the discussion. Tony, I'm going to bring this back to you. There was another interesting point in our prep session. AI is giving business users far more autonomy now, right? Someone who might never have written a traditional code can now create Workiva scripts.
They can build applications. They can obviously build automations by describing what they want. You referred to some of this as vibe coding. There's a huge opportunity for this, right? Because consumers can, or customers can just build it what they want. But there's also a huge risk. How do you give business users that autonomy without creating that next generation of uncontrolled spreadsheets, macros, and those black box workflows?
Yeah. It's an incredibly relevant question, more so than ever. When we think about- We think about this challenge as leaders. It's, well, how do I empower people to grow and do something that me, individually as a leader, didn't think about? How do we foster that creativity, but also protect our organization from the risk? And those key person dependencies that get created by that, the risk that you've got an application that's not truly production-worthy, that's not really hardened, and so maybe there's data leakage risks. All those things really need to come into play. I really think about it in terms of incubation. If you think about how startups work, right? You've got incubators that live out a lot in the Bay Area, which obviously you're out there, you're familiar with that.
Absolutely.
That's the model.
Yeah.
Right? It is the let people play, give them a sandbox, give them an opportunity to come up with a really great idea, and then have a committee that evaluates that. Does this make sense? Should we continue to invest in this? How does this fit into our enterprise architecture? Are we building something that we should be buying? Or are our needs specific enough that building it makes sense? Those are all questions that your organizations individually have to answer, but don't shut down innovation.
Because even if that innovation isn't right for your organization long term, what you have done is you have maybe surfaced something that the organization is feeling as a pain point, and now you can march toward the, quote, "right answer," right? Who knows what the right answer is? That, again, depends on your organization. But empowering your people to be creative is going to be a better outcome for your business, just doing it smartly.
Yeah. That's a—
Yeah, maybe—
—Good answer.
—Sorry to jump in. I was just going to say, I think I really like what you're saying, Tony. I think that's spot on. I think what I've seen organizations do really well is kind of democratize that through hackathons, just through data access, like really encouraging people to get out there and use these tools. And when you have it connected into a good data model, a good governed model, you have confidence at least they're getting the right answers or getting the answers that make sense or can be tied back to a validated discrete data point. And that's very compelling.
That's what everyone, I think, should be thinking about. And then you couple that with a governance process too, right? You think about, okay, does this start to touch more than three people or regulatory or investor or client? Then it becomes something that maybe IT gets involved as they take it into more of a product view of the world. You don't want to diminish or box in that creativity. Yeah, definitely I love that thought process, Tony.
I love your point of democratization of information. Brandon, I want to get your view on this. From an audit and GRC perspective again, is it a point where more democratization actually increases control risk there?
Yeah, it does certainly increase the risk if there is not a clear process in place to take those maybe minimum viable products that people are developing or incubating and then kind of commit and harden those within the business process.
Yeah.
If you are kind of letting people go rogue without applying the structure for how those solutions will ultimately get adopted and pass an audit and make sure that they're on board with what IT is going to support long term. If you are able to put that structure in place and encourage people to follow it, I think that's how you reduce the risk and ultimately get people to be more encouraged to build more of these solutions, because they'll kind of see the impact that it can have on the organization when there's a path to take those and apply them more broadly.
But if you do have people that are just kind of vibe coding small parts of their job in a non-IT sanctioned way, there is absolutely a ton of risk that gets introduced into that process. Especially, like I mentioned earlier, just kind of the pace of change and the pace at which new tools are coming out, there's a lot of risk that if on the IT side of things you're not keeping up with what's being made available to your organization—
Yeah.
—You're going to lose control over what people are ultimately able to do, and that's just going to create continuously more risk if there isn't kind of a structure that, again, encourages that ideation and creation of new things, but has kind of a clear path to how that gets committed to being a part of the business process.
Makes sense. To summarize this section, the foundation is simply not clean data. It is structured data, it is context, it is controls and access, lineage, and probably boundaries of how data can be used within the platform. I think once we have that figured out, the next question becomes, what should we actually allow AI to do? Now, let's assume everything is true, we have the data foundation, and it's trustworthy. The next design question is not where we can put AI, but I guess what role should AI actually play inside these enterprise workflows?
Brandon, I want to kick off this discussion with you, because I know during our conversation you mentioned RSM and you're already using AI internally within your delivery teams, including within the data management suite and to help automate some of the more complex GRC configurations. I want to make that more tangible to the audience. Can you just walk us through one example where AI is augmenting a data management, GRC, or an audit implementation today? A quick follow-up is, what is AI doing that traditional automation wasn't particularly good at doing?
Yeah, absolutely. I would say really the way that we're using it from an implementation perspective is primarily to really accelerate the work that our team is doing. From a Wdata perspective, we have query libraries that we have built, and we've given them context around the business purpose of this is the system that this is pulling from, this is what it's trying to achieve, so that the next time we're trying to achieve something similar or something adjacent to that, we can really arrive at a query or an output that's going to work quicker. Similarly, on the GRC side of things, we have YAML libraries that we use to create things within the UI in the platform quicker. Really, it's kind of augmenting the work that the team is doing.
It's not necessarily doing it for them, but it's getting them to a point where we can get things in front of a client quicker, and that was really kind of the business problem that I think my team and I were after solving is when we do discovery and design with clients, and we produce these big documents that maybe they read, maybe they don't. Ultimately, it's all kind of conceptual until they can actually see their data and their process in the system. The faster that we can arrive at that, the more time we can spend with people making those kind of fine-tuning and doing those tweaks within the system that really get people to where they want to go.
That's really where we've leveraged it a lot, is to just be able to kind of get to that initial product faster so the clients can see it and we can spend more time working on the things that are more important to them or maybe catching a gap that we wouldn't have caught just through a conceptual discussion. But by using it to accelerate that work, we get them to that first pass much faster.
That's awesome to hear. Tony, there was something that you mentioned at the start of the webinar, deterministic automation, right? As Brandon Rubin has been explaining, how they've been using AI in their configurations, in their day-to-day implementations for delivery purposes, where do you draw the line between a deterministic automation where you need the output and the results to be fixed based on the inputs, but where do you have AI-driven decision-making? How do you make those decisions? What's the line between those two things?
It's a really good question. It's one that I think a lot of people are struggling with.
Yeah.
A lot of organizations have this mandate from the top, "Use AI." If there's a more generic term that you're ever going to hear, it's "Use AI." Naturally, when we get mandates from senior leadership, we want to find a way to do those things, right? Because these are senior-level people, they see something that we probably don't, they probably have access to information that we don't, the direction they're giving us is something that we generally follow because—
Yeah.
—We should. Problem is, if we are not sure how to use AI or where to use AI, then everything starts to look like a nail with an AI hammer in your hand.
Yeah.
If I bring this into something hyper-focused, Brandon mentioned Wdata.
I think AI is fantastic for helping you build a Wdata query. I would not use AI to run a Wdata query, at least not as part of my process that is going to refresh my spreadsheets as part of my reporting every single month. That is complete overkill. Can AI do it? Sure. Will it arrive at the same result, deterministic? Probably. But it's not needed, right? That's a classic use case for just pure automation.
Right.
Now, on the flip side, where would I use AI? Well, maybe I want to take MCP, which, sorry folks, acronym alphabet soup here. MCP, if you don't know what it is, don't feel bad. Not everybody does, right? That's kind of the don't be alone on this. MCP, I like to just describe it as basically like an add-in, like an Excel add-in. If you're used to using those things and you connect to whatever thing, system that you've got in your enterprise and pulled data into your Excel spreadsheet before you used Workiva, okay, that's an add-in or a plug-in. It's the same thing for general-purpose AI.
If you've got Claude, if you've got ChatGPT, MCP is just a protocol, it stands for Model Context Protocol, who cares, that tells us how do we have that general-purpose AI talk to the different systems in our organization and bring that data together. Where I'm going with all that, right, the really long-winded thing that I'm saying here is, all right, I said don't use AI to run Wdata queries. Well, most of the time. But if I'm trying to take data that lives in a Wdata table and I want to combine that with some data that maybe lives somewhere outside of my Workiva ecosystem, maybe it's other systems in my organization, maybe it's information on the internet—
Right.
—And I want to combine that together, well, then that's a great use case for AI with Wdata.
Yeah.
You really have to look at it and go, "What am I trying to achieve here, and is it more automation-based? Is it the same steps that don't require any thinking?" Changing the time period that I want to get back doesn't require thinking. That's just an input. Now, if I want to take data and I want to combine that with other things and start to analyze it, well, then that's a little bit more of an AI use case, or a lot more of an AI use case. Hopefully that helps people think about the difference between AI and automation.
Absolutely. Before we get to next question, who primarily owns automation and AI-enabled workflows in your organization today? That's a great question for the topic that's going to come next. But the options are the business or the process owners, central automation or data team, IT team, and then if the answer is ownership is unclear or shared informally? Going to give it a few seconds. Okay. Tony, you brought up an interesting point of MCPs. Brandon, I want to ask this question to you, or Steven, if you want to join in as well. What should the AI be allowed to understand?
What should the AI be allowed to recommend, and what should it be allowed to execute, right? With MCPs, now you have the power to get information from multiple systems. You can curate data from multiple systems. You can get data from Workiva as well. Does MCP let me begin with a question. What should AI be allowed to understand? What should it recommend, and what should we actually allow it to execute in an enterprise organization?
Yeah, I think for all three of those, and I will for now ignore kind of the data security and privacy side of it, because if I didn't, that's all we'd talk about for another hour. But I would say in terms of what it should be able to understand, it should really be the data and the context that's relevant to the ask, right? This again gets back to kind of what Tony was saying earlier about not being an AI hammer looking for nails, right? You really need to think about what is it that the solution is trying to accomplish, and focus the data that it has access to on that problem, right?
Yeah.
If you are trying to solve for a financial reporting problem, you should probably keep it to your general ledger data and whatever other data you might be using to compile those financial reports, versus if you give it fairly open-ended access to a data warehouse, one, it is going to look at a bunch of stuff it does not need. Two, once it does that, you run a much higher risk of it making an incorrect inference or recommendation that it looks like it can back up with numbers that maybe don't really make sense or aren't relevant to your problem. In terms of what it should be able to understand, I would say really anything around the business challenge that you're trying to solve. In terms of what it should be allowed to recommend, I'd say anything that you feel confident in its recommendation for.
Really anything that you've been able to test and reproduce results around, for let's say a given period of time, then you can take that and say, "Okay, we feel comfortable with it making recommendations in the future, citing the right evidence because we know that it's giving us a consistent response, albeit just over new data." In terms of what it's allowed to execute, that is of course where you have to be very, very, very, very careful, right? I'd say it can't really It shouldn't be able to execute anything that a person hasn't approved at some point in time, especially if it's anything that is going to be impacting your financial data.
That's where you really have to be the most careful, is making sure that if it does execute something, there is at least a clear lineage of who approved this, what did it recommend before it went and executed, and then what process was in place to review and make sure that what it executed was actually what you asked it to do.
Got it. The human in the loop concept that we usually hear about. Steven, any examples or thoughts on that?
Yeah, so a couple things maybe just to comment on. I think you've seen a lot of these SaaS providers are rolling out MCP, and there could be read-only or read-write. I think what I find very powerful about Workiva's approach to AI is it's very intentional. What I mean by that is, basically read-only access via the MCP. What that unlocks is, going back to the conversation we were having earlier on trusted data, you now have at your fingertips through the screen you're interacting with for all your other Claude or ChatGPT interactions, you now have access to trusted data because it's connected back to Workiva. They can pull your revenue number, your AUM number off of a financial statement for a specific fund at a specific time, and you have confidence that you're getting that answer back, and it's the right answer.
That unlocks so much for your executive teams. I think that's really one thing that I'm really encouraged about around the Workiva platform. Going back to what Brandon was talking about, the human in the loop piece, I think that's been one of the most interesting concepts that we've been spending a lot of our time talking about. I really look at it as kind of a three-part framework. So you have your AI agents, right? They can interpret, they can orchestrate, and they can act, right? Things like ingesting information, extracting data, classifying information, identifying patterns, orchestrating workflows, et cetera.
Right.
Then you have the deterministic piece, which should be your calculations and your rules enforcement. So, you want to rely on that deterministic model essentially as your code base. That's a very powerful piece. Then the whole thing is wrapped around the human in the loop with the direction, the judgment, the approvals, the sign-offs. That connection of that three-part framework is really powerful in where our clients are going, and I think enabled through what Workiva's providing around it, both their agents as well as their MCP.
Nice. That's a great way to tie it all together. Tony, I do have a question for you, and I want your reaction on this. We obviously have just talked about democratization of data. We have talked about vibe coding. Now we're talking about MCPs and just having access to a lot of data, obviously with the own capabilities. We are obviously going one step further where AI is not just generating code, it's not just orchestrating. It can now interact with multiple systems, multiple governed enterprise capabilities across the entire whole enterprise. Does that make you more excited about autonomy? Or does it make you more concerned about the guardrails that we need to think about of putting those in an enterprise?
Guardrails all day.
Yeah.
It's rare that I'll be as definitive as that, because I usually like to think about the impact of other answers. For me, we've all had this experience when you're working with AI. If you don't ask it a question in the right way, if you're too generic, you get a generic answer, you get a bad answer. You get an answer where AI might want to tell you the answer that it thinks that you want to have, right? AI is meant to please you in a lot of ways.
Yeah.
I think the guardrails, and going back to something that Steven brought up, Workiva's been doing a really good job at making purposeful AI.
Yeah.
I think they're building a lot of those guardrails in. Even with those, I still want that human in the loop for anything that is material. If I'm preparing a presentation or a customer's preparing a presentation and they're getting ready to send that to the ELT, do you really want something to go to the CFO without a human ever looking at it just because AI produced it?
Yeah.
Probably not. Likewise, I doubt you'd want a filing directly to the SEC based on no human being involved, right?
Yeah.
Those are things that I really want some guardrails around.
Yeah.
I do think that things like, yeah, go ahead.
Sorry, I was just going to say, if you think about last year, Amplify, the big headline was the assured integrated reporting, right? That was the value proposition, was tying controls and governance, integrations, and reporting together. That does not change in the world of AI. That's still the value of Workiva, and it's still how everything needs to be built around that process, right? I think, Tony, that's kind of where you were going.
Yeah, 100%.
Yep, that makes sense. That's 100% accurate, right? Just to close off this section, right, a strong AI-ready workflow gives AI a bounded role, right? You have your trusted inputs come in. AI is great for adding context or reading context and adding judgment where it's useful. Deterministic controls validate where you need that trust. You have to have humans remain accountable at the right points in your workflow, and then the workflow needs to have an audit trail, a lineage, and a fallback path, right? That makes a great AI workflow in your enterprise. I deliberately saved this section, which is operating model, for last, because we can have a fantastic architecture, right? We can have clean data. We can expose different capabilities through APIs, MCPs, and introduce awesome agents. But eventually, there's a very basic question that needs to be answered.
Who owns this once it becomes business critical? In your isolated experiments, it's all good, but who actually owns it? Tony, I know in our discussion, you made the case that operating model and governance should come before, or at least alongside your technical implementation. What do customers need to decide organizationally today before they start scaling AI-enabled automation in their organization?
I'm going to kick this to Brandon and Steven, this question as well. But the thing that I've seen projects go sideways on, and guys, back me up here if you think I'm right or challenge me if you think I'm wrong, but when a project doesn't have an owner, it's almost doomed to fail. I don't think that AI should be thought of, and the adoption of AI should be thought of in any other way than as a project.
The organization needs to identify what are the needs that they're trying to solve, what does the architecture look like, what's the design of this, and how do we then go to that production state, and how do we keep it going and maintain it and iterate it and update it, and all those things that go along with a typical technology implementation that sometimes people want to bypass and shortcut. I don't think you can shortcut it. I think you need an owner. Honestly, given what AI is, I think the owner lives in IT. This is where business partnership becomes incredibly important in an organization. Workiva, historically, at least in the financial reporting side of the house, has been very much contained in the office of the CFO.
Right.
I think that that's going to naturally have to shift, and our partnership with the IT teams, working together to get better outcomes, is going to become vitally important. It can't be an adversarial thing. That's not to say that it always is, but sometimes it is. Let's be honest about that.
Yeah.
Those walls have to come down. I think IT owns AI and its adoption across the organization, because as Steven alluded to, so many SaaS vendors are including AI. If you don't start to put some standards and governance around it becomes the Wild West, and you don't have good outcomes.
Absolutely. Brandon, do you agree with that viewpoint that it needs to be with IT?
Yeah, I do. I think at least the architecture and the intake for AI solutions should be run through IT. At the end of the day, it is software that people are deploying, and most companies already have a process by which they procure and configure and integrate software, and that is typically going to be run through someone in IT who has the bigger picture in mind of the overall enterprise architecture.
Yeah.
I absolutely still think that IT is going to need to be at the head of this, but I do think that within various functions of the organization and the governance structure that IT allows, there does need to be an individual operating model for those teams, especially as people start to deploy a lot more task-specific agents, and as those tasks get more complex, there's going to need to be clear ownership, not just of the overall AI strategy, but okay, now you have this agent that does this task.
Right.
Who's in charge of making sure that it operated correctly? And who thinks about when the business context changes, how are we going to update that, and who's responsible for that? So, I think there needs to be an owner at the top, but there also needs to be a pretty clear operating model within individual functions.
Makes sense.
Yeah, just to pile on. I completely agree with you guys. I think, I talked about it a bit before, there's an opportunity to create a governance structure, right? You want to enable your teams and all across the business to get in and get involved, but you need to set those guardrails. You can set those controls through managing centralized skills libraries that are cascaded down to teams to set parameters around what people can and can't do.
You can create rules around what it can touch and what it can't touch. But ultimately, at a certain point, when it becomes valuable to an organization and it starts touching multiple teams or people, it needs to move into an IT, forward deployed engineers, you need to have the sophisticated people that know how to build applications take that to the next level. Because the risk of what we're seeing right now is, it kind of a nod that's everywhere. There was RPA running wild, and no one knew what these were doing.
Yeah.
If we're not careful, that is the exact same pattern that will unfold. Without what the evolution of RPA became business process management, which is a governed orchestrated workflow. Without that in place, RPA would have failed. That's the big lesson there, and I think that does sit with IT to administer and support the business and establish those controls.
Thank you. Thank you all for your thoughts. I think it makes sense to sit within IT. I think there is another question in a lot of organizations where we're discussing, right, should it be a shared model with some of the business teams and IT, or should it just be IT? I think, not to say a very generic answer, it depends. It depends on the organization, how it's structured, how the operating model works in those organizations. Now, before we close this webinar with the lightning round, in the interest of time, I want you all to put in the questions in the Q&A section. We won't be able to answer them now, but we will absolutely reply to them via email. So please get your questions in the Q&A section, and we will get to them as soon as possible after the webinar. Wait.
Give me a sec. I have a question for all of you. Just 30 seconds each. Organizations who are thinking of AI and AI workflows today, what should they stop doing today? What should they start doing today? And what should they continue to do that they are doing today? Steven, I will ask you first, then we will go to Brandon and then Tony.
This is a great question. I would say stop using people as the integration layer between disconnected systems. Start with one high-value workflow, prove it in production, and build from there, keeping AI and agents as reusable code bases. And then remember, AI interprets and orchestrates. The deterministic model is the code that calculates, and the humans provide the judgment and accountability.
Awesome. Brandon?
Yeah, I would say I think people should stop making using AI the goal, right? Think about the actual business problem versus leading with the solution. I would say they should start making sure that they have a good understanding of their data. So not just thinking about the one report that they pull every month, but thinking about the broader context and where it comes from. And continue, I do think, despite what I said earlier, people should continue experimenting, just trying to do that within some pretty clear bounds that their organization sets.
Right. Tony, bring us home.
Sure. I am going to ask you to remind me of the third question, but I remember the first two. Stop using AI, and this is a little repetitive of what everyone is saying, but stop using AI where automation should be used. I would say start is step back. Start stepping back and designing a process, and then figuring out how the technology goes along with it. What does the whole thing look like, and what are the outcomes that I need to achieve? That is going to unearth a lot more of where AI can plug in, as opposed to trying to figure it out after you have reached the goal line. Ankit, remind me of the third question.
What should they continue to do?
What should they continue to do?
Yeah.
Continue to add that context to your data. We talked about it at the beginning of the webinar. We have mentioned it a few times here. Data alone means nothing. Data with context is information. The more context you give your information, whether that is simple things like describing what that data is, or more formal, taking things out of brains, I think Steven made reference to this, out of people's brains and actually codifying it. Those actions are what people should continue to do if they want to be successful with AI in the long term.
That is a great thought. I just want to thank you, Tony, Steven, Brandon, for getting onto this webinar and having a great discussion. Thank you again for taking out time and having the conversation with us. It has been a pleasure.
Absolutely.
Thank you.
This was pretty good.
Thanks.
That concludes our webinar.