Aishwarya Shah on Responsible AI, Data Governance and Leadership

I used to think I had taken several different turns in my career. Now I see one continuous thread: I have always been interested in how systems work, where they break, and how to make them work better.

Mechanical engineering gave me that instinct first. You quickly learn that one component rarely exists in isolation; a small failure can tell you about the larger system. When I moved into data analytics, the objects changed, but the way I thought did not. Instead of mechanical systems, I was looking at datasets, models, processes, and decisions. At Northeastern, I worked on machine learning, forecasting, database development, risk analysis, and cloud-oriented projects. Later, financial and investment analytics taught me that data is never just technical—it carries business consequences.

That became even clearer in enterprise operations. I found myself increasingly drawn not only to what a number said, but to where it came from, what happened to it along the way, who relied on it, who owned the decision, and what happened when something went wrong. That curiosity is what eventually pulled me toward data governance and responsible AI.

That journey has also had an international dimension. I began my career in India as a graduate engineer, then worked in analyst roles before an opportunity took me to the UK, where I worked in investment analysis in Edinburgh, Scotland. My career eventually brought me to the United States. Working across India, the UK, and the USA has shaped how I think about people, culture, and work just as much as the different roles themselves. I have seen how culture shapes communication, decision-making, collaboration, and how people approach ambiguity. It taught me not to assume that one way of working is universally right, and to spend more time listening and understanding context before trying to solve a problem.

Much of my work lives in the space between a technical issue and its business consequence. In a large financial-services environment, a process can span data sources, transformations, applications, operational teams, product teams, and reporting outputs. When something surfaces downstream, the visible issue is often only the last step in a much longer story.

My role is often to help make that story visible. I work on exception governance, data lineage, operational documentation, process transparency, ownership, and business readiness. I spend a lot of time connecting people who each understand one part of the process and turning that distributed knowledge into something the organization can use.

One lesson I have learned is that recurring operational problems are frequently knowledge problems as much as technology problems. If the logic exists only in one developer's head, if business teams use different terminology, or if every cycle requires rediscovering the same root cause, that is a governance problem.

The work I enjoy most is taking something that initially feels messy—multiple teams, different interpretations, technical dependencies, manual workarounds—and creating enough structure that people can see the process, understand the decision points, and know what happens next.

For me, being a bridge is not about sitting in the middle and passing messages back and forth. It is about understanding why each side is asking the questions it is.

A developer may explain an issue through an API, a transformation, a schema, or a piece of logic. A business user may describe the same issue as an exception, an incorrect output, a late-cycle problem, or a manual correction. Neither is wrong. They are looking at the same system from different points.

I have come to believe that being a bridge can be a specialization in itself. Translation, synthesis, governance, and product thinking are not softer versions of technical work. In complex enterprises, they are what make technical work usable.

Responsible AI becomes meaningful when it changes a decision someone makes. Principles matter, but eventually someone has to decide what data can be used, what level of human oversight is appropriate, what needs to be documented, how a model is monitored, who can challenge an output, and who is accountable when the system behaves unexpectedly.

I also do not believe every use case should carry the same governance burden. Good governance should be risk-sensitive and proportionate. If controls become disconnected from the actual risk, teams either slow down unnecessarily or find ways around them.

The goal is not to make innovation harder. It is to make adoption trustworthy enough to last.

Because AI cannot magically repair uncertainty in the data beneath it; if an organization cannot answer basic questions about a critical data element—where it originated, how it was transformed, what it means, who owns it, and whether it is appropriate for a particular use—putting AI on top of that uncertainty doesn't strengthen the foundation.

The same discipline becomes even more important in AI, where data can influence training, retrieval, inference, evaluation, and automated actions. Definitions, lineage, ownership, controls, documentation, exception handling, and monitoring are not side activities. They are infrastructure for trustworthy AI.

AI may be new, but many of the problems it exposes—unclear ownership, inconsistent definitions, fragmented processes, undocumented assumptions—are governance problems organizations have been carrying for years.

It was less one dramatic moment and more a pattern I kept noticing. I was in conversations where very capable people tried to solve the same recurring issue, but each person held only one part of the context. Someone knew the technical logic. Someone else knew the operational workaround. Another person knew why the business cared. The missing piece was often a shared view of the whole process.

I naturally wanted to build that shared view: map the flow, normalize the language, document the logic, identify ownership, and turn repeated troubleshooting into institutional knowledge. I realized I was more energized by creating that clarity than by solving only the individual incident in front of me.

That is probably my most personal definition of governance: making important knowledge less dependent on who happens to be in the room.

Those activities keep me from becoming too comfortable inside one organizational perspective. Speaking pushes me to test whether I can explain an idea clearly to people who don't live in my day-to-day context. Reviewing research makes me slow down and ask whether a claim is actually supported. Judging exposes me to people building with emerging technology in very different ways. Mentoring reminds me that a career makes much more sense in retrospect than it does while you are living it.

One especially meaningful experience was speaking on ethical AI and inclusive innovation. It forced me to think beyond governance as a set of enterprise controls and toward leadership: who gets included in technology decisions, what assumptions we normalize, and how leaders create the conditions for responsible adoption.

I also value research and professional service because they make me a better practitioner. I have reviewed research papers, served on technical program committees, chaired sessions, judged technology initiatives, and published technical work. Each role asks for a slightly different kind of rigor. Together, they have made me more comfortable asking difficult questions without assuming there is one perfect answer.

I know what it feels like to have interests that do not fit neatly into one job title. Earlier in my career, I had a technical background, but I was also drawn to strategy, communication, business problems, and leadership. It can be confusing to be good at something but not want that one skill to define your entire career.

That is why I particularly enjoy mentoring people who are trying to bridge disciplines. I recently worked with an early-career mentee who had a strong technical foundation but was more excited by strategy and by helping business and technology teams solve problems together. I recognized that immediately. My advice was not to abandon the technical background, but to use it as credibility while developing the skills required to translate, prioritize, influence, and frame problems.

The mentors who helped me most did not hand me a career map. They helped me understand how to think about the next decision. That is the kind of mentor I try to be.

Education has been one of the ways I have deliberately reinvented myself. Moving from mechanical engineering into a master's program in data analytics was a major transition. It required me to become comfortable being a beginner again—learning statistics, machine learning, programming, databases, cloud concepts, and the language of a completely different discipline.

I am continuing that habit as a doctoral candidate pursuing a DBA in Business Intelligence and Data Analytics. At this stage, I am less interested in collecting another credential than in becoming more rigorous about how I connect research, organizational behavior, strategy, and technology. Working full-time while studying also keeps the academic questions grounded. I can read a framework and immediately ask: what would this look like inside a real enterprise with competing priorities, legacy processes, governance requirements, and people who still have to get the work done?

That interaction between research and practice is increasingly important to how I want to grow.

Sometimes people discuss AI transformation as though the model is the transformation. It is not. A model can be impressive and still fail to create durable enterprise value.

Transformation happens when the operating model around it changes: data is reliable, workflows are redesigned, accountability is clear, employees know when to trust or challenge the system, controls match the risk, and the organization can learn from failures. That requires product thinking, change management, governance, architecture, operations, and leadership—not just model performance.

I think the organizations that mature fastest will stop treating governance as the team that arrives at the end to approve something. Governance should be part of design. It should help teams ask better questions earlier, when changing the approach still costs little.

The real opportunity is not simply to automate existing work. It is to rethink how decisions and knowledge move through the organization.

Clarity before control.

In complex environments, it is tempting to respond to every problem by adding another process, approval, spreadsheet, or meeting. Sometimes that is necessary, but often the first need is simpler: make the current system visible.

Once people can see the same picture, accountability becomes much easier to establish. I have found that some of the most useful leadership work isn't having the answer; it is creating the conditions for the right answer to emerge and remain available after the conversation ends.

Do not force yourself into a professional identity too early. Build real depth, but pay attention to the problems that consistently pull your attention.

My mechanical engineering degree still influences how I think. My analytics training gives me technical fluency. My finance and operations experience taught me about risk, controls, and business consequences. Governance taught me to think about ownership and institutional knowledge. Speaking and mentoring taught me to communicate across very different audiences. None of those experiences replaced the previous one; they compounded.

I would also tell people to become very good at asking basic questions without embarrassment. Complex organizations can make simple questions feel unsophisticated: What does this field actually mean? Why do we do this step? Who uses this output? What happens if it is wrong? Those questions often uncover the most important problems.

You do not need to know your final title. You need to keep building a body of skills that makes you useful on increasingly important problems.

I want the next chapter of my career to be about helping organizations move from AI enthusiasm to responsible, enterprise-scale capability. I am especially interested in the intersection of AI governance, data lineage, operational intelligence, product strategy, and organizational change, where technology decisions become business and leadership decisions.

I want to stay close to practitioner work because real operating constraints are where leadership ideas are tested. At the same time, I want to continue writing, researching, speaking, reviewing, and mentoring because those experiences expose me to different perspectives and keep expanding how I think.

Long term, I want my work to contribute to an AI transformation where governance isn't seen as a brake on innovation, but as part of the architecture that makes innovation credible. Technology will continue to change, but the leadership challenge will remain: creating clarity amid complexity, bringing different perspectives together, and building systems people can understand and trust. If I can help organizations innovate while making decisions more transparent, responsible, and sustainable, that is the kind of impact I want my career to have.