AI Readiness Prediction Tool for Micro-Businesses
Advisor: Joe Haines
Internship Location: Mitre
Onsite Mentor: Kam Him Tam (Jeff)
Small businesses are told they need AI to stay competitive, yet 74% of companies that try it fail to derive any value, and 43% abandon their systems within 18 months. The problem isn't that the technology doesn't work; it's that businesses don't know if they're ready for AI in the first place. They either avoid it completely or go in unprepared and essentially waste money. I hope to build a machine learning tool specifically for micro-businesses that predicts whether they're ready to adopt AI. Micro-businesses face different challenges than larger small businesses, including fewer resources, less technical expertise, and higher failure rates with new technology. Previous research has studied AI adoption across all SMEs, but I want to see whether the factors that predict success differ for the smallest businesses. Using real data from over 11,000 European businesses, I'll train a model to identify what drives AI readiness in micro-businesses specifically. The final product will be a user interface where micro-business owners answer questions about their company and get a personalized readiness prediction with specific recommendations. I'll be interning at MITRE Corporation in cybersecurity during this project to develop my technical and analytical skills. This tool could help the most vulnerable businesses avoid mistakes when considering AI adoption.
Project Blog
Post 1: Getting Started...
Hi guys,
Welcome to my first EVER blog post!! I will be researching the challenges faced by micro-businesses in AI adoption. My interest in this research stems from seeing a constant disconnect between technology adoption and implementation realities. Throughout my computer science work and previous internships using machine learning and data analysis, I have become more and more interested in how technical solutions can adress buisiness challengers rather than technology for its own sake. My project is essentially me trying to combine both of my interests. I am specifically focusing on micro-businesses, as I found a trend that existing AI adoption tends to treat all small and medium businesses as the same category. A business with five employees faces very different constraints than one with fifty, yet both receive similar advice and assessment frameworks. I wanted to check out the gap between research categories and practical realities.
My project is going to be conducted independently, involving analyzing the Flash Eurobarometer dataset, which contains responses from over 11,000 European businesses. I will also be interning at MITRE Corporation in their cybersecurity division. My internship is going to focus on different technical aspects, but these are still going to give me analytical and problem-solving skills that I can apply to complement the research method for this project. This internship will also give me context for understanding how organizations process technological adoption decisions.
Stay tuned for the next update!
Week 1: Foundations
Hi again, guys,
My first week was all about setting up the foundations for my project. I spent most of my time doing background research, getting the dataset, and setting up my technical environment.
I read through existing research on AI adoption challenges in small businesses. This helped me refine my approach. I looked at theoretical frameworks that guide technology adoption research. One framework that keeps showing up is TOE (Technology-Organization-Environment). It says technology adoption depends on three things: the technology itself, how the organization is set up, and the external business environment. Understanding these frameworks can help me organize my analysis later.
I downloaded the Flash Eurobarometer 486 dataset from the GESIS data archive. I also got all the documentation and the codebook. The dataset comes in multiple volume files. I'll need to combine them later during the data preparation phase. The full questionnaire documents can help me understand how survey responses create usable variables. The dataset contains responses from over 11,000 businesses across Europe, which should give me enough data to train a solid model.
I also spent some time this week getting my Python environment set up properly with some of the tools I'll need for the analysis and modeling work. Pretty standard stuff, but hopefully I won't run into technical issues later when I'm actually working with the data.
Catch you next time!
Week 2: MITRE and Dataset Mapping
Welcome back to my third blog post
This week, I officially started my internship at MITRE as an engineering intern. Most of the week was spent on onboarding and getting familiar with the organization and how everything works. The first few days were all about orientation and introduction. I'm working in the cybersecurity division, which is a bit different from my research project but where I can hopefully learn some skills that I can to my own research.
One area I've been learning more about is large language models (LLMs). I have some knowledge about this from some previous experience, but now I'm learning more about how businesses implement them and the security considerations that come with deploying AI systems in real-world environments.
On the research side, I started looking more into the dataset documentation more carefully. I'm mapping out which survey questions correspond to the variables I need for analysis. The codebook has over 50 potential predictor variables, so I'm working on organizing them into categories based on the TOE framework I mentioned last week: technology factors, organizational factors, and environmental factors. I'm also getting a better sense of how the actual data is structured and what preprocessing I'll need to do.
Week 3: Cybersecurity and Initial Dataset Review
This week at MITRE was focused on building my technical skills in cybersecurity and systems automation. Memory-level security vulnerabilities became a major learning area. I studied how RAM stores data, how attackers exploit unencrypted memory, and how hardware-level encryption solutions prevent these attacks. To visualize these concepts, I wrote Python scripts that simulate how data appears in memory with and without encryption.
I also progressed in my Python automation work this week. I got more practice working with real enterprise systems by writing scripts that interact with REST APIs (basically, how different software programs talk to each other over the internet) and handle authentication (the login/security verification part).
On the research side, I moved from documentation review to actually working with the dataset. The Flash Eurobarometer 486 data files were loaded into Python, and I started looking at how they were structured.
Now that I can see the actual data, identifying key variables is easier. Question 23 asks about AI adoption and serves as my target variable. From the 50+ options, I'm narrowing down to about 20-25 predictors that fit the technology-organization-environment (TOE) framework categories.
One thing I noticed is that there's missing data scattered throughout the dataset. The AI adoption distribution shows an imbalance of more non-adopters than adopters. So I have to clean the dataset.
Week 4: Data Cleaning and RAM Security
This week at MITRE, I built a proof of concept demonstrating memory-level security vulnerabilities. When programs run on a computer, they temporarily store information in RAM (the computer's short-term memory). The goal was to show the difference between encrypted and unencrypted memory when systems store sensitive information. I created a simulation that stores data in RAM and then demonstrates what an attacker could access in two scenarios: one where the memory is unencrypted (everything is readable as plain text, like reading a regular document) and one where it's encrypted (the data is scrambled, so the attacker only sees random numbers).
The interesting part was understanding that the vulnerability isn't necessarily in the software itself, but in the underlying infrastructure. Even secure applications can leak sensitive data if the machine they're running on doesn't have proper memory protection. In production environments, hardware-level encryption solutions (special security features built directly into the computer's processor chips, like AMD SEV or Intel TDX) protect memory at the chip level. This means the data is scrambled automatically by the hardware itself, making it unreadable even to someone with physical access to the machine.
On the research side, I finished the data cleaning work this week. The Flash Eurobarometer dataset had some missing values scattered throughout; basically, some businesses didn't answer certain survey questions. I used mean imputation for numerical variables (filling in missing numbers with the average of what other businesses reported) and mode imputation for categorical ones (filling in missing categories with whatever answer was most common). For variables where more than 30% of the data was missing, I removed them entirely rather than trying to fill in too many blanks, since that would just be guessing.
I also created some derived features, new variables calculated from existing data, to make patterns easier to spot. For example, I calculated "years in business" by subtracting the founding year from the current year, and I created a digital maturity score by combining several technology adoption questions into one overall measure of how digitally advanced each business is.
The next step was filtering the dataset into two groups: micro-businesses with 1-9 employees and larger small businesses with 10-49 employees. This is the core of what makes my research different from existing studies. I split each group into training sets (80% of the data the model learns from) and test sets (20% of the data I save to evaluate how well the model works on businesses it hasn't seen before). This prevents the model from just memorizing patterns and lets me see if it can actually make good predictions.
I started building the logistic regression models to test the TOE framework hypotheses. Logistic regression is a statistical method that predicts yes/no outcomes, in this case, whether a business adopted AI or not, based on various factors. The idea is to see whether technology factors (like cloud computing), organization factors (like company size and skills), and environmental factors (like infrastructure quality) actually predict AI adoption, as the theory says they should, and whether those relationships differ between the smallest businesses and slightly larger ones. Next week, I'll finish running these models and start comparing the results across the two business size groups.
Week 5: Building Real Attack Demonstrations + ML
This week at MITRE, we moved beyond the simulated proof of concept and started working with actual running systems. The Python scripts from earlier weeks were helpful to understand the concept, but they weren't real LLM tests, as it was just fake data we created ourselves. To make the demonstration actually convincing, we needed to show a real attack on a real system.
We set up an actual language model running locally so we'd have a real LLM to test against, not a simulation. We then built a simple web-based chat interface from scratch so someone could have a real conversation with it. This required figuring out how to connect the frontend (the webpage where you type messages) to the backend API (the interface that sends prompts and gets responses back). Getting the real-time message display working took some debugging, but now you can interact with it like a normal chat application.
Essentially, what I made was a Python script that demonstrates how an attacker could read from a running process's memory. On Linux, every program's memory is accessible if you have the right permissions. This is standard operating system functionality, not anything extra. The script finds the target process, scans through its RAM regions, and extracts readable text (specifically, I'm looking for conversation content and user messages).
This is the actual vulnerability we were trying to show, but now it's physically accessible from a chat with an LLM. When you type something into the chat, the scanner can pull that text directly out of the process's memory and display it. It's demonstrating an actual attack on actual memory from an actual running system.
The next step is comparing this against a system with proper memory protection to show the difference in what an attacker can access.
The web development experience I got this week is also helpful to my research project since I'm planning to build a similar interface where users input their business information and get AI readiness predictions back. So understanding how to structure a web application with a backend that does the processing and a frontend that displays results is pretty helpful.
On the research side, I started building the Random Forest models this week. Random Forest is a machine learning algorithm that creates multiple decision trees. Each tree makes predictions by asking a series of yes/no questions about the data (like "Does this business use cloud computing? Yes. Do they have innovation programs? No."), and then combines all the trees' predictions. Unlike a logistic regression, which assumes variables affect outcomes in simple linear ways, Random Forest can check for specific patterns like "cloud adoption only matters if the business also has skilled workers."
I'm training separate Random Forest models for micro-businesses (1-9 employees) and larger small businesses (10-49 employees). The process involves testing different parameter settings, like how many trees to build, how deep each tree can grow, and how many variables each tree considers when splitting. Finding the right combination takes trial and error because too simple and the model misses patterns, too complex and it just memorizes the training data instead of learning generalizable rules.
I'm also working on preventing overfitting, which happens when the model performs great on training data but poorly on new data it hasn't seen before. The way I'm checking for this is by evaluating the model on the test set I saved earlier (the 20% of data the model never trained on). If training accuracy is 90% but test accuracy is only 60%, that means the model memorized the training data rather than learned it.
Week 6: Model Finalization
This week at MITRE, we continued adding to the live memory demonstration and started working towards encrypting the LLM. The web chat interface and memory scanner are working reliably now, so we've been testing them with different types of conversations and more to make sure the scanner consistently gets the results we want. We also started documenting how the demonstration works to explain the technical setup, what the attack looks like step by step, and what the results show.
I also spent time this week learning more about how web applications handle real-time data updates. For the chat reader interface from the RAM, we needed the conversation to update smoothly as messages come in, which meant understanding how to structure the frontend code to look for new data from the back without constantly refreshing the page. Similar to last week, this is also really relevant to my research project since the AI readiness tool will need to process user input and display results dynamically.
On the research side, I finished building the Random Forest models this week. After testing different hyperparameter configurations last week. I settled on 100 trees with a maximum depth of 15 based on initial cross-validation results during training. The models are built and trained for both micro-businesses (1-9 employees) and larger small businesses (10-49 employees), but I still need to run them on the test set to get final performance numbers and compare them to each other.
Right now, I'm making sure everything is working correctly before I evaluate the final results. So I'm checking that the models are loading the right data, that the predictions are outputting in the correct format, and that the evaluation metrics are calculating properly. I also need to verify that the train/test split happened correctly and that there's no data leakage (where information from the test set accidentally gets used during training, which would make the results unreliable).
Week 7: Testing Encryption and Models
This week at MITRE, we were focused on setting up the encrypted memory environment to complete the side-by-side demonstration. Setting up hardware-level memory encryption is more complex than I initially expected. We need to configure a virtual machine with encrypting technologies like AMD SEV (Secure Encrypted Virtualization) or Intel TDX (Trust Domain Extensions) enabled, which means we need specific hardware support and BIOS/firmware settings that are harder to implement with all of MITRE's restrictions. The encrypted VM needs to run the same setup as the unencrypted (the language model, the web interface, and allow the memory scanner to run), but when the scanner tries to read memory, it should only see encrypted gibberish instead of plaintext.
I'm also starting to prepare for the end-of-spring presentation at MITRE. This is when I present what the demonstration shows, why it matters from a security perspective, and how hardware-level encryption protects against memory-reading attacks.
On the research side, I started running the Random Forest models on the test set this week. Last week I finished building the models and verifying that everything was set up correctly, making sure the data was loading properly, the predictions were outputting in the right format, and there was no data leaking between the training and test sets. This week was about actually running the evaluation.
I'm also calculating different things to understand how well the models perform. I'm using accuracy to see the percentage of businesses the model classifies correctly overall. Precision to see how many of the businesses the model predicted would adopt AI that actually did adopt it (important for avoiding false positives). And I'm using recall to see how many of the actual AI adopters the model successfully identified (important for not missing businesses that would succeed). Finally, ROC-AUC gives me an overall score from 0 to 1 showing how well the model distinguishes between adopters and non-adopters.
I'm running these separately for the micro-business model (1-9 employees) and the larger small business model (10-49 employees), and comparing both to the logistic regression baseline I set from Week 4. The process is taking longer than expected because I'm also checking for issues like class imbalance (when there is more non-adopters than adopters in the dataset) and making sure the results are statistically reliable.
Weeks 8-9: Completed Demonstration and Model Evaluation
These last few weeks at MITRE the main focus was completing the encrypted vs unencrypted side by side demonstration. Both virtual machines are now fully set up, one running with AMD SEV-SNP enabled for hardware level memory encryption and one with no encryption. Both VMs run the same Llama 3.2 model through the chat interface we built. The demo is now fully working end to end. Using QEMU's management socket we can freeze either VM, dump its memory to a file, and search through it. On the unencrypted machine the conversation comes back in plain text exactly as the user typed it. On the encrypted machine the same attack returns nothing (the dump completes but the contents are completely unreadable ciphertext thanks to SEV-SNP encrypting RAM at the hardware level).
I also finished preparing the presentation for the end of spring internship at MITRE. The presentation walks through what the demonstration shows, why memory-level vulnerabilities matter, and how hardware encryption solves the problem.
On the research side, I finished running the Random Forest models and got the evaluation results this week. The models perform significantly better than the logistic regression baseline, which confirms the idea that AI adoption follows complex patterns that simple statistics can miss. I'm now working on analyzing the feature importance rankings to see which variables matter most for each business size group. The comparison between micro-businesses and larger SMEs is leaning towards showing what I expected: technology factors matter more for the smallest businesses while organizational factors are much more important for larger ones. I'm also starting to add more to the results and analysis section for the final paper now that I have more leads.